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Field of the Invention 



This invention relates to the accomplishment of moderately complex computer 
applications by a combination of hardware and software, and more particularly to methods of 
5 optimizing the implementation of portions of such computer applications in hardware, 
hardware thus produced, and to the resultant combination of hardware and software. 



This application claims priority from provisional patent application Serial No. 
60/445,339 filed February 5, 2003 in the name of Aravind R. Dasu et al. entitled 

10 "Reconfigurable Processing," provisional patent application Serial No. 60/490,162 filed July 
24, 2003 in the name of Aravind R. Dasu et al. entitled " Algorithm Design for Zone Pattern 
Matching to Generate Cluster Modules and Control Data Flow Based Task Scheduling of the 
Modules," provisional patent application Serial No. 60/493,132 filed August 6, 2003 in the 
name of Aravind R. Dasu et al. entitled "Heterogeneous Hierarchical Routing Architecture," 

15 and provisional patent application Serial No. 60/523,462 filed November 18, 2003 in the 
name of Aravind R. Dasu et al. entitled "Methodology to Design a Dynamically 
Reconfigurable Processor," all of which are incorporated herein by reference. 



A number of techniques have been proposed for improving the speed and cost of 
20 moderately complex computer program applications. By moderately complex computer 
programming is meant programming of about the same general level of complexity as 
multimedia processing. 

Multimedia processing is becoming increasingly important with wide variety of 
applications ranging from multimedia cell phones to high definition interactive television. 
25 Media processing involves the capture, storage, manipulation and transmission of multimedia 
objects such as text, handwritten data, audio objects, still images, 2D/3D graphics, animation 
and full-motion video. A number of implementation strategies have been proposed for 
processing multimedia data. These approaches can be broadly classified based on the 
evolution of processing architectures and the functionality of the processors. In order to 
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provide media processing solutions to different consumer markets, designers have combined 
some of the classical features from both the functional and evolution based classifications 
resulting in many hybrid solutions. 

Multimedia and graphics applications are computationally intensive and have been 
5 traditionally solved in 3 different ways. One is through the use of a high speed general 

purpose processor with accelerator support, which is essentially a sequential machine with 
enhanced instruction set architecture. Here the overlaying software bears the burden of 
interpreting the application in terms of the limited tasks that the processor can execute 
(instructions) and schedule these instructions to avoid resource and data dependencies. The 

10 second is through the use of an Application Specific Integrated Circuit (ASIC) which is a 
completely hardware oriented approach, spatially exploiting parallelism to the maximum 
extent possible. The former, although slower, offers the benefit of hardware reuse for 
executing other applications. The latter, albeit faster and more power, area and time efficient 
for a specific application, offers poor hardware reutilization for other applications. The third 

15 is through specialized programmable processors such as DSPs and media processors. These 
attempt to incorporate the programmability of general purpose processors and provide some 
amount of spatial parallelism in their hardware architectures. 

The complexity, variety of techniques and tools, and the high computation, storage 
and I/O bandwidths associated with multimedia processing presents opportunities for 

20 reconfigurable processing to enables features such as scalability, maximal resource utilization 
and real-time implementation. The relatively new domain of reconfigurable solutions lies in 
the region of computing space that offers the advantages of these approaches while 
minimizing their drawbacks. Field Programmable Gate Arrays (FPGAs) were the first 
attempts in this direction. But poor on-chip network architectures lead to high reconfiguration 

25 times and power consumptions. Improvements over this design using Hierarchical Network 
architectures with RAM style configuration loading have lead to a factor of two to four times 
reduction in individual configuration loading times. But the amount of redundant and 
repetitive configurations still remains high. This is one of the important factors that leads to 
the large overall configuration times and high power consumption compared to ASIC or 

30 embedded processor solutions. 

A variety of media processing techniques are typically used in multimedia processing 
environments to capture, store, manipulate and transmit multimedia objects such as text, 
handwritten data, audio objects, still images, 2D/3D graphics, animation and full-motion 
video. Example techniques include speech analysis and synthesis, character recognition, 
H5615Sv2 2 
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audio compression, graphics animation, 3D rendering, image enhancement and restoration, 
image/video analysis and editing, and video transmission. Multimedia computing presents 
challenges from the perspectives of both hardware and software. For example, multimedia 
standards such as MPEG-1, MPEG-2, MPEG-4, MPEG-7, H.263 and JPEG 2000 involve 
5 execution of complex media processing tasks in real-time. The need for real-time processing 
of complex algorithms is further accentuated by the increasing interest in 3-D image and 
stereoscopic video processing. Each media in a multimedia environment requires different 
processes, techniques, algorithms and hardware. The complexity, variety of techniques and 
tools, and the high computation, storage and UO bandwidths associated with processing at 

10 this level of complexity presents opportunities for reconfigurable processing to enables 
features such as scalability, maximal resource utilization and real-time implementation. 

To demonstrate the potential for reconfiguration in multimedia computations, the 
inventors have performed a detailed complexity analysis of the recent multimedia standard 
MPEG-4. The results show that there are significant variations in the computational 

1 5 complexity among the various modes/operations of MPEG-4. This points to the potential for 
extensive opportunities for exploiting reconfigurable implementations of multimedia/ 
graphics algorithms. 

The availability of large, fast, FPGAs (field programmable gate arrays) is making 
possible reconfigurable implementations for a variety of applications. FPGAs consist of 

20 arrays of Configurable Logic Blocks (CLBs) that implement various logical functions. The 
latest FPGAs from vendors like Xilinx and Altera can be partially configured and run at 
several megahertz. Ultimately, computing devices may be able to adapt the underlying 
hardware dynamically in response to changes in the input data or processing environment and 
process real time applications. Thus FPGAs have established a point in the computing space 

25 which lies in between the dominant extremes of computing, ASICS and software 

programmable/ instruction set based architectures. There are three dominant features that 
differentiate reconfigurable architectures from instruction set based programmable computing 
architectures and ASICs: (i) spatial implementation of instructions through a network of 
processing elements with the absence of explicit instruction fetch-decode model (ii) flexible 

30 interconnects which support task dependent data flow between operations (iii) ability to 
change the Arithmetic and Logic functionality of the processing elements. The 
reprogrammable space is characterized by the allocation and structure of these resources. 
Computational tasks can be implemented on a reconfigurable device with intermediate data 
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flowing from the generating function to the receiving function. The salient features of 
reconfigurable machines are: 

• Instructions are implemented through locally configured processing elements, 
thus allowing the reconfigurable device to effectively process more instructions into 

5 active silicon in each cycle. 

• Intermediate values are routed in parallel from producing functions to 
consuming functions (as space permits) rather than forcing all communication to take 
place through a central resource bottleneck. 

• Memory and interconnect resources are distributed and are deployed based on 
10 need rather than being centralized, hence presenting opportunities to extract parallelism 

at various levels. 

The networks connecting the Configuration Logic Blocks or Units (CLBs) or 
processing elements can range from full connectivity crossbar to neighbor only connecting 
mesh networks. The best characterization to date which empirically measures the growth in 
1 5 the interconnection requirements with respect to the number of Look-Up Tables (LUTs) is 
the Rent's rule which is given as follows: 

N i0 = C N P gat e S 

where N ,Q corresponds to the number of interconnections (in/out lines) in a region 
containing N gate s. C and p are empirical constants. For logical functions typically p ranges 

20 from 0.5<p<0.7. 

It has been shown [I] (by building the FPGA based on Rent's model and using a 
hierarchical approach) that the configuration instruction sizes in traditional FPGAs are higher 
than necessary, by at least a factor of two to four. Therefore for rapid configuration, off-chip 
context loading becomes slow due to the large amount of configuration data that must be 

25 transferred across a limited bandwidth I/O path. It is also shown that greater word widths 
increase wiring requirements, while decreasing switching requirements. In addition, larger 
granularity data paths can be used to reduce instruction overheads. The utility of this 
optimization largely depends on the granularity of the data which needs to be processed. 
However, if the architectural granularity is larger than the task granularity, the device's 

30 computational power will be under utilized. Another promising development in efforts to 
reduce configuration time is shown in [2]. 

Most of the current approaches towards building a reconfigurable processor are 
targeted towards performance in terms of speed and are not tuned for power awareness or 
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configuration time optimization. Therefore certain problems have surfaced that need to be 
addressed at the pre-processing phase. 

First, the granularity or the processing ability of the Configurable Logic Units (CLUs) 
must be driven by the set of applications that are intended to be ported onto the processing 
5 platform. Some research groups have taken the approach of visual inspection [3], while 
others have adopted algorithms of exponential complexity [4,5] to identify regions in the 
application's Data Flow Graphs (DFGs) that qualify for CLUs. None of the current 
approaches attempt to identify the regions through an automated low complexity approach 
that deals with Control Data Flow Graphs (CDFGs). 

10 Secondly, the number of levels in hierarchical network architecture must be 

influenced by the number of processing elements or CLUs needed to complete the task / 
application. This in turn depends on the amount of parallelism that can be extracted from the 
algorithm and the percentage of resource utilization. To the best of our knowledge no 
research group in the area of reconfigurable computing has dealt with this problem. 

1 5 Thirdly, the complex network on the chip, makes dynamic scheduling expensive as it 

adds to the primary burden of power dissipation through routing resource utilization. 
Therefore there is a need for a reconfiguration aware scheduling strategy. Most research 
groups have adopted dynamic scheduling for a reconfigurable accelerator unit through a 
scheduler that resides on a host processor [6,7]. 

20 The increasing demand for fast processing, high flexibility and reduced power 

consumption naturally demand the design and development of a low configuration time 
aware-dynamically reconfigurable processor. 

It is an object, therefore, to provide a low area, low power consuming and fast 
reconfigurable processor. 

25 Task scheduling [1] is an essential part of the design cycle of hardware 

implementation for a given application. By definition, scheduling refers to the ordering of 
sub-tasks belonging to an application and the allocation of resources to these tasks. Two 
types of scheduling techniques are static and dynamic scheduling. Any application can be 
modeled as a Control-Data Flow Graph. Most of the current applications provide a large 

30 amount of variations to users and hence are control-dominated. To arrive at an optimal static 
schedule for such an application would involve a highly complex scheduling algorithm. 
Branch and Bound is an example of such an algorithm with exponential complexity. Several 
researchers have addressed task scheduling and one group has also addressed scheduling for 
conditional tasks. 
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Any given application can be modeled as a CDFG G(V,E). V is the set of all nodes of 
the graph. Theses nodes represent the various tasks of the CDFG. E is the set of all 
communication edges. These edges can be either conditional or unconditional. There are two 
possible methods of scheduling this CDFG which have been listed below. 
5 Static scheduling of tasks is done at compile time. It is assumed that lifetimes of all 

the nodes are known at compile time. The final schedule is stored on-chip. During run-time, 
if there is a mistake in the assumption of lifetime of any node, then the schedule information 
needs to be updated. Advantage of this method is that worst-case execution time is 
guaranteed. But, a static schedule is always worse than a dynamic schedule in terms of 
10 optimality. Some of the existing solutions for static scheduling are stated here. 

Chekuri [2] discusses the earliest branch node retirement scheme. This is applicable 
for trees and s-graphs. An s-graph is a graph where only one path has weighted nodes. In this 
case, it is a collection of Directed Acyclic Graphs (DAGs) representing basic blocks which 
all end in branch nodes, and the options at the branch nodes are: exit from the whole graph or 
15 exit to another branch node. The problem with this approach is that it is applicable only to 

small graphs and also restricted to S-graphs and trees. It also does not consider nodes mapped 
to specific processing elements. 

Pop [3] tackles control task scheduling in 2 ways. The first is partial critical path 
based scheduling. But they do not assume that the value of the conditional controller is 
20 known prior to the evaluation of the branch operation. They also propose the use of a branch 
and bound technique for finding a schedule for every possible branch outcome. This is quite 
exhaustive, but it provides an optimal schedule. Once all possible schedules have been 
obtained, the schedules are merged. The advantages are that it is optimal, but it has the 
drawback of being quite complex. It also does not consider loop structures. Scheduling of 
25 tasks is done during run-time. Main advantage of such an approach is that there is no need for 
a schedule to be stored on-chip. Moreover, the schedule obtained is optimal. But, a major 
limiting factor is that the schedule information needs to be communicated to all the 
processing elements on the chip at all time. This is a degrading factor in an architecture 
where interconnects occupy 70% of total area. 
30 Jha [4] addresses scheduling of loops with conditional paths inside them. This is a 

good approach as it exploits parallelism to a large extent and uses loop unrolling. But the 
drawback is that the control mechanism for having knowledge of each iteration and the 
resource handling that iteration is very complicated. This is useful for one or two levels of 
loop unrolling. It is quite useful where the processing units can afford to communicate quite 
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often with each other and the scheduler. But in our case, the network occupies about 70% of 
the chip area [6] and hence cannot afford to communicate with each other too often. 
Moreover the granularity level of operation between processing elements is beyond a basic 
block level and hence this method is not practical. 
5 Mooney [5] discusses a path based edge activation scheme. This means that if for a 

group of nodes (which must be scheduled onto the same processing unit and whose schedules 
are affected by branch paths occurring at a later stage) one knows ahead of time the branch 
controlling values, then one can at run time prepare all possible optimized list schedules for 
every possible set of branch controller values. This method is very similar to the partial 

10 critical path based method proposed by Pop discussed above. It involves the use of a 
hardware scheduler which is an overhead. 

Existing research work on scheduling applications for reconfigurable devices has been 
focused on context-scheduling. A context is the bit-level information that is used to configure 
any particular circuit to do a given task. A brief survey of research done in this area is given 

15 here. 

Noguera [7] proposes a dynamic scheduler and four possible scheduling algorithms to 
schedule contexts. These contexts are used to configure the Dynamic Reconfiguration Logic 
(DRL) blocks. This is well-suited for applications which have non-deterministic execution 
times. 

20 Schmidt [8] aims to dynamically schedule tasks for FPGAs. Initially, all the tasks are 

allocated as they come till the entire real estate is used up. Schmidt proposes methods to 
reduce the waiting time of the tasks arriving next. A proper rearrangement of tasks currently 
executing on the FPGA is done in order to place the new task. A major limitation of this 
method is that it requires knowing the target architecture while designing the rearrangement 

25 techniques. 

Fernandez [9] discusses a scheduling strategy that aims to allocate tasks belonging to 
a DFG to the proposed MorphoSys architecture. All the tasks are initially scheduled using a 
heuristic-based method which minimizes the total execution time of the DFG. Context 
loading and data transfers are scheduled on top of the initial schedule. Fernandez tries to hide 
30 context loading and data transfers behind the computation time of kernels. A main drawback 
is that this method does not apply for CDFG scheduling. 

Bhatia [ 1 0] proposes a methodology to do temporal partitioning of a DFG and then 
scheduling the various partitions. The scheduler makes sure that the data dependence between 
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the various partitions is maintained. This method is not suited for our purpose which needs 
real-time performance. 

Memik [11] describes super-scheduler to schedule DFGs for reconfigurable 
architectures. He initially allocates the resources to the most critical path of the DFG. Then 
5 the second most critical path is scheduled and so on. Scheduling of paths is done using Non- 
crossing Bipartite matching. Though the complexity of this algorithm is less, the schedule is 
nowhere near optimal. 

Jack Liu [12] proposes Variable Instruction Set Computer (VTSC) architecture. 
Scheduling is done at the basic block level. An optimal schedule to order the instructions 
1 0 within a basic block has been proposed. This order of instructions is used to determine the 
hardware clusters. 

An analysis of the existing work on scheduling techniques for reconfigurable 
architectures has shown that there is not enough work done on static scheduling techniques 
for CDFGs. This shows the need for a novel method to do the same. 

1 5 The VLSI chip design cycle includes the steps of system specification, 

functional design, logic design, circuit design, physical design, fabrication and 
packaging. The physical design automatic of FPGA involves three steps which include 
partitioning, placement and routing. 

Despite advances in VLSI design automation, the time it takes to market for a chip is 

20 unacceptable for many applications. The key problem is time taken due to fabrication of 

chips and therefore there is a need to find new technologies, which minimize the fabrication 
time. Gate Arrays use less time in fabrication as compared to full custom chips since only 
routing layers are fabricated on top of pre-fabricated wafer. However fabrication time for gate 
arrays is still unacceptable for several applications. In order to reduce the time to fabricate 

25 interconnects; programmable devices have been introduced which allow users to program the 
devices as well as interconnect. 

FPGA is a new approach to ASIC design that can dramatically reduce manufacturing 
turn around time and cost. In its simplest form an FPGA consists of regular array of 
programmable logic blocks interconnected by a programmable routing network. A 

30 programmable logic block is a RAM and can be programmed by the user to act as a small 
logic module. The key advantage of FPGA is re-programmability. 

The VLSI chip design cycle includes the steps of system specification, functional 
design, logic design, circuit design, physical design, fabrication and packaging. Physical 
design includes partitioning, floor planning, placement, routing and compaction. 
!156l5Sv2 8 
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w. V 

The physical design automation of FPGAs involves three steps, which include 
partitioning, placement, and routing. Partitioning in FPGAs is significantly different than the 
partitioning s in other design styles. This problem depends on the architecture in which the 
circuit has to be implemented. Placement in FPGAs is very similar to the gate array 
5 placement. Routing in FPGAs is to find a connection path and program the appropriate 

interconnection points. In this step the circuit representation of each component is converted 
into a geometric representation. This representation is a set of geometric patterns, which 
perform the intended logic function of the corresponding component. Connections between 
different components are also expressed as geometric patterns. Physical design is a very 

10 complex process and therefore it is usually broken into various subsets. 

The input to the physical design cycle is the circuit diagram and the output is the 
layout of the circuit. This is accomplished in several stages such as partitioning, floor 
planning, placement, routing and compaction. 

A chip may contain several transistors. Layout of the entire circuit cannot be handled 

15 due to the limitation of memory space as well as computation power available. Therefore it is 
normally partitioned by grouping the components into blocks. The actual partitioning process 
considers many factors such as the size of the blocks, number of blocks, and the number of 
interconnections between the blocks. The set of interconnections required is referred as a net 
list. In large circuits the partitioning process is hierarchical and at the topmost level a chip 

20 may have 5 to 25 blocks. Each block is then partitioned recursively into smaller blocks. 

This step is concerned with selecting good layout alternatives for each block as well 
as the entire chip. The area of each block can be estimated after partitioning and is based 
approximately on the number and type of commonness in that block. In addition interconnect 
area required within the block must also be considered. Very often the task of floor plan 

25 layout is done by a design engineer rather than a CAD tool due to the fact that human is 
better at visualizing the entire floor plan and take into account the information flow. In 
addition certain components are often required to be located at specific positions on the chip. 
During placement the blocks are exactly positioned on the chip. The goal of placement is to 
find minimum area arrangement for the blocks that allows completion of interconnections 

30 between the blocks while meeting the performance constraints. Placement is usually done in 
two phases. In the first phase initial placement is done. In the second phase the initial 
placement is evaluated and iterative improvements are made until layout has minimum area 
or best performance. 
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The quality orplacement will not be clear until the routing phase has been completed. 
Placement may lead to un-routable design. In that case another iteration of placement is 
necessary. To limit the number of iterations of the placement algorithm an estimate of the 
required routing space is used during the placement process. A good routing and circuit 
5 performance heavily depend on a good placement algorithm. This is due to the fact that once 
the position of the block is fixed; there is not much to do to improve the routing and the 
circuit performance. 

The objective of routing is to complete the interconnection between the blocks 
according to the specified net list. First the space that is not occupied by the blocks (routing 
10 space) is partitioned into rectangular regions called channels and switchboxes. This includes 
the space between the blocks. The goal of the router is to complete all circuit connections 
using the shortest possible wire length and using only the channel and switch boxes. This is 
usually done in two phases referred as global routing and detailed routing phases. In global 
routing connections are completed between the proper blocks disregarding the exact 
1 5 geometric details of each wire. For each wire global router finds a list of channels and 

switchboxes to be used as passageway for that wire. Detailed routing that completes point-to- 
point connections follows global routing. Global routing is converted into exact routing by 
specifying the geometric information such as location and spacing of wires. Routing is a very 
well defined studied problem. Since almost all routing problems are computationally hard the 
20 researchers have focused on heuristic algorithms. 

Compaction is the task of compressing the layout in all directions such that the total 
area is reduced. By making the chip smaller wire lengths are reduced which in turn reduces 
the signal delay. 

Generally approaches to global routing are classified as sequential and concurrent 
25 approaches. 

In one approach nets are routed one by one. If a net is routed it may block other nets 
which are to be routed. As a result this approach is very sensitive to the order of the nets that 
are considered for routing. Usually the nets are ordered with respect to their criticality. The 
criticality of a net is determined by the importance of the net. For example a clock net may 
30 determine the performance of the circuit so it is considered highly critical. However 

sequencing techniques don't solve the net ordering problem satisfactorily. An improvement 
phase is used to remove blockages when further routing is not feasible. This may also not 
solve the net ordering problem so in addition to that 'rip-up and reroute 1 technique [Bol79, 
DK82] and 'shove-aside' techniques are used. In rip-up and reroute the interfering wires are 
Il56158v2 10 
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ripped up and reroutecTto allow routing of affected nets. Whereas in shove aside technique 
wires that allow completion of failed connections are moved aside without breaking the 
existing connection. Another approach [De86] is to first route simple nets consisting of only 
two or three terminals since there are few choices for routing such nets. After the simple nets 
5 are routed, a Steiner Tree algorithm is used to route intermediate nets. Finally a maze routing 
algorithm is used to route the remaining multi-terminal nets that are not too numerous. 

To match the needs of the future moderately complex applications, provided is the 
first of a series of tools intended to help in the design and development of a dynamically 
reconfigurable multimedia processor. 

1 0 Brief Summary 

In accordance with this invention, designing processing elements based on identifying 
correlated compute intensive regions within each application and between applications results 
in large amounts of processing in localized regions of the chip. This reduces the amount of 
reconfigurations and hence gives faster application switching. This also reduces the amount 

1 5 of on-chip communication, which in turn helps reduce power consumption. Since 

applications can be represented as Control Data Flow Graphs (CDFGs) such a pre-processing 
analysis lies in the area of pattern matching, specifically graph matching. In this context a 
reduced complexity, yet exhaustive enough graph matching algorithm is provided. The 
amount of on-chip communication is reduced by adopting reconfiguration aware static 

20 scheduling to manage task and resource dependencies on the processor. This is 

complemented by a divide and conquer approach which helps in the allocation of an 
appropriate number of processing units aimed towards achieving uniform resource utilization. 

In accordance with one aspect of the present invention a control data flow graph is 
produced from source code for an application having complexity approximating that of 

25 MPEG-4 multimedia applications. From the control data flow graph are extracted basic 
blocks of code represented by the paths between branch points of the graph. Intermediate 
data flow graphs then are developed that represent the basic blocks of code. Clusters of 
operations common to the intermediate data flow graphs are identified. The largest common 
subgraph is determined from among the clusters for implementation in hardware. 

30 Efficiency is enhanced by ASAP scheduling of the largest common subgraph. The 

ASAP scheduled largest common subgraph then is applied to the intermediate flow graphs to 
which the largest common subgraph is common. The intermediate flow graphs then are 
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scheduled for reduction^ time of operation. This scheduling produces data patches 
representing the operations and timing of the scheduled intermediate flow graphs having the 
ASAP scheduled largest common subgraph therein. The data patches are then combined to 
include the operations and timing of the largest common subgraph and the operations and 
5 timing of each of the intermediate flow graphs that contain the largest common subgraph. 

At this point, it will be appreciated, the utilization of the hardware that represents the 
ASAP-scheduled largest common subgraph by the operations of each implicated intermediate 
flow graph needs scheduling. Bearing in mind duration of use of the hardware representing 
the largest common subgraph by the operations of each of the implicated intermediate flow 
1 0 graphs, hardware usage is scheduled for fastest completion of the combined software and 

hardware of operations of all affected intermediate flow graph as represented in the combined 
data patches. Our target architecture is a reconfigurable architecture. This adds a new 
dimension to the CDFG discussed above. A new type of edge between any two nodes of the 
CDFG that will be implemented on the same processor is possible. Let us call this a 
1 5 "Reconfiguration edge". A reconfiguration time can be associated with this edge. This 
information must be accounted for while scheduling this modified CDFG. Method of 
scheduling according to the present invention treats reconfiguration edges in the same way as 
communication edges and includes the reconfiguration overhead while determining critical 
paths. This enables employment of the best CDFG scheduling technique and incorporation of 
20 the reconfiguration edges. 

To realize the largest common flow graph in hardware, processor component layout 
and interconnections by connective fabric needs to be addressed. 

In accordance with the invention, a tool set that will aid the design of a dynamically 
reconfigurable processor through the use of a set of analysis and design tools is provided. A 
25 part of the tool set is a heterogeneous hierarchical routing architecture. Compared to 

hierarchical and symmetrical FPGA approaches building blocks are of variable size. This 
results in heterogeneity between groups of building blocks at the same hierarchy level as 
opposed to classical H-FPGA approach. Also in accordance with this invention a 
methodology for the design and implementation of the proposed architecture, which involves 
30 packing, hierarchy formation, placement, network scheduler tools, is provided. 

The steps of component layout and interconnectivity involve (1) partitioning - cluster 
recognition and extraction, (2) placement - the location of components in the available area 
on a chip, and (3) routing - the interconnection of components via conductors and switches 
with the goal of maximum speed and minimum power consumption. 
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Brief Description of the Drawings 



Fig. 1 is a flow chart that indicates major steps in the programming of a 
reconfigurable circuit device in accordance with the present invention; 

Figs. 2 A and B are illustrations of a pair of control flow graphs from input source 
5 code representing separate operations of the application to be run by a reconfigurable circuit; 

Fig. 3 is an enlarged illustration of a basic block extracted from one of the control 
flow graphs of Fig. 2, and shows the individual lines of code represented by the block; 

Fig. 4 A and B are illustrations of a pair of intermediate data flow graphs derived 
from a pair of basic blocks of Figs. 2 A and 2B; 
10 Fig. 5 is an illustration of a largest common subgraph shared by the intermediate data 

flow graphs of Figs. 4 A and 4B; 

Figs. 6 A and B are illustrations of the data flow graphs of Figs. 4 A and 4B 
incorporating the largest common subgraphs of Fig. 5 and following ASAP scheduling; 



1 5 blocks in a loop; 

Fig. 8 is a block diagram of a control flow graph having only a single basic block also 
in a loop; 

Fig. 9 A and B are block diagrams of control flow graphs having a single nested loop 
with more than one basic block; 
20 Fig. 10 is a block diagram of a control flow graph having multilevel nested loops; 

Fig. 1 1 is a block diagram of a control flow graph with basic blocks classified into 
decision, merge and pass categories; 

Fig. 12 is a flow graph plotted with flow left to right, plotting operations against 

cycles; 

25 Fig. 12A is a diagrammatic illustration of "bins" into which edges in the graph of Fig. 

1 2 have been sorted; 

Fig. 1 3 is a flow graph plotted with flow left to right, plotting operations against 

cycles; 



30 have been sorted the edges of the graph of Fig. 13; 

Fig. 14 A is a graphical illustration of a sorting into bins of edges of a shown graph 
Gl for comparison with a further graph G2 of Fig. 14 B; 



Fig. 7 is an illustrative block diagram of a control flow graph having one of its basic 



Fig. 1 3 A is a diagrammatic illustration of further, modified bin sequence to which 



1 1561 58v2 



t. 



✓!^p?i> Docket No. 91 38-01 4S 

Fig. 14 B is aHIagrammatic illustration like that of Fig. 14 A with the further graph 
G2 which is taken from the graph Gl of Fig. 14 A; 

Fig. 1 5 is a graphical illustration of an architecture for effecting the operation 
represented by the first control flow graph of Fig. 2; 
5 Fig. 1 6 is a graphical illustration of architecture for effecting the operation 

represented by the second control flow graph of Fig. 2; 

Fig. 1 7 is a graphical representation of an architecture combining the architectures of 
Figs. 15 and 16 through the use of multiplexers; 

Fig. 18 is diagrammatic illustration of an exemplary data flow graph with nodes cross- 
1 0 hatched to indicate those needing scheduling onto the same processor; 

Fig. 1 9 is a further diagrammatic illustration of a common data flow graph indicating 
those nodes needing to be scheduled onto the same processors; 

Figs. 20 - 25 are individual data flow graphs common to the common data flow graph 
of Fig. 19 in increasing order of modified partial critical path method delay; 
1 5 Fig. 26 is a graphical illustration of two processes to be scheduled by partial critical 

path; 

Fig. 27 is a diagrammatic illustration of a pair of processes to be scheduled by partial 
critical path, like those of Fig. 26; 

Fig. 28 is a diagrammatic illustration of a tree of possible paths used in scheduling the 
20 example of Fig. 19; 

Fig. 29 A and B are comparative task graphs for an exemplary task and show the 
effect of reconfiguration time on a schedule; 

Fig. 30 is a scheduling chart, each row representing processes scheduled on a unique 
processing element; 

25 Fig. 31 is a diagrammatic illustration of updating of logic schedule manager and 

network schedule manager for a pair of processes, PA and PB; 

Fig. 32 is a diagrammatic block diagram of a reconfigurable processor having its data 
routing fabric scheduled by a network schedule manager and its logic units scheduled by 
logic schedule managers; 
30 Fig. 33 is a diagrammatic illustration in flow chart form of the configuring of a 

reconfigurable media processor in accordance with the invention; 

Fig. 34 is a three dimensional graphical illustration of spatial and temporal constraints 
on the configuration of the processor of Fig. 33; 

Fig. 35 is graphical comparative illustration for four programmable gate arrays; 
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Fig. 36 A and B are comparative block diagram illustrations of alternative building 
block arrangements using multiple A and singular B building blocks to form clusters; 

Fig. 37 is a diagrammatic illustration of clusters of building blocks forming modules 
in the architecture of a reconfigurable processor; 

Fig. 38 is a diagrammatic illustration of a destination block to which data is switched 
via a global gateway switch from a local global bus; 

Fig. 39 is a block diagram in the form of a flow chart illustrating the methodology of 
the invention in configuring a reconfigurable processor; 

Fig. 40 A and B are diagrammatic illustrations of the scheduling of an if else 
statement from the building blocks configured in Fig. 39; 

Fig. 41 A is a cost matrix of six blocks used in placement of the blocks in configuring 
the processor being configured in Fig. 39; 

Fig. 41 B is a block diagram illustration of the preplacement of the blocks of Fig. 41 

A; 

Fig. 42 is a flow chart illustrative of the design flow for layout of the reconfigurable 
processor; 

Fig. 43 is a control flow linked list that contains control flow information; 
Fig. 44 is an illustration of a modified structure obtained from the control flow linked 
list of Fig. 43; 

Fig. 45 is an illustration of zones formed in the modified list structure of Fig. 44; 

Fig. 46 is a diagrammatic illustration of parent-child relationships among modified list 
structure zones of Fig. 45; 

Fig. 47 is a diagrammatic illustration of the zone structure of Fig. 46 indicating link 
cancellations; 

Fig. 48 is a diagrammatic illustration of the zone structure of Fig. 47 with the 
cancelled links removed; and 

Fig. 49 is a diagrammatic sequential ordering of the zones with annotations. 



Turning to Fig. 1 , source code in C or C++ for an MPEG4 multimedia application that 
includes a pair of its operations " Affine Transform," and 11 Perspective,' 1 are input to a Lance 
compiler utility 101 running its "Show CFG" operation. This outputs Control Flow Graphs 
(DFGs). Control Flow Graphs for the Affine Transform and Perspective are shown in Fig. 2. 



Detailed Description 
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As seen in the Affine CFG of Fig. 2, the Affine Transform Control Flow Graph is composed 
of a series of basic blocks 106, 108, 1 10, 1 12 and 1 14. The CFG of the multimedia 
component Perspective is similarly composed of basic blocks. As shown in Fig. 3, CFGs 
output by the Lance compiler utility 101 are actually more textual than their depictions in 
5 Figs. 2 A and B, but are readily understood to describe basic blocks and their 

interconnections. The Affine Transform has a number of its blocks 108, 110, 112 arranged in 
loops. Whereas block 106 is a preloop listing. 

Visually, at present, the many CFGs of the multimedia application are inspected for 
similarity among large control blocks. How big the candidate blocks should be is a 

10 judgement call. Similar blocks of more than 50 lines in two or more CFGs are good 

candidates for development of a Largest Common Flow Graph among them whose operations 
are to be shared as described below. Smaller basic blocks can similarly be subjected to the 
development of largest common flow graphs as described below, but at some point the 
exercise returns insignificant time and cost savings. The Affine Transform preloop basic 

15 block 106 has 70 instructions. This is shown in the enlarged depiction of block 106 in Fig. 3. 
The Perspective preloop basic block 1 18 has 85 instructions. Those Affine and Perspective 
preloop instructions are as follows: 
Affine preloop basic block 106 





t541 




s_178/2; 


20 


t348 




2 * i0_166; 




t349 




t348 + du0_172; 




t350 




t541 *t349; 




t352 




2 *j0_167; 




t353 




t352 + dv0_173; 


25 


t354 




t541 * t353; 




t356 




2 * il_168; 




t357 




t356 + dul_174; 




t358 




t357 + du0_172; 




t359 




t541 * t358; 


30 


t361 




2 *jl_169; 




t362 




t361 +dvl_175; 




t363 




t362 + dv0_173; 




1364 




t541 * t363; 




t366 




2 * i2_170; 
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t367 = t366 + du2_176; 

t368 = t367 + du0_172 

t369 = t541 * t368; 

t371 = 2*j2_171; 
5 t372 = t371 +dv2_177; 

t373 = t372 + dvO_173; 

t374 = t541 * t373; 

t542 = 256; 

t375 = i0_166 + t542; 
10 t376= 16*t375; 

t543 = r_179*t359; 

t544= 16 * il_168; 

t21 =t543-t544; 

t381 =-80 *t21; 
15 t385 = t542 * t21; 

t386 = t381 +t385; 

t545= 176; 

t387 = t386 / t545; 

t388 = t376 + t387; 
20 t546= 16 * j0_167; 

t547 = r_179 * t354; 

t22 = t547 - t546; 

t394 = -80 * t22; 

t395 = r_179 * t364; 
25 t396= 16*jl_169; 

t397 = t395 - 1396; 

t398 = t542 * t397; 

t399 = t394 + t398; 

t400 = t399 / t545; 
30 t401 =t546 + t400; 

t548= 16 * i0_166; 

t 404 = r_179*t350; 

t406 = t404 - 1548; 

t407 = -112 *t406; 
11561 58v2 17 
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t408 - 


r 179 * t369' 


X409 = 


16 * i2 170' 


t410 = 


t408 - 1409' 


t4 1 1 = 


t542 * t410* 


t412 = 


t407 + 1411" 


t549 = 


144- 


t4i3 = 


t412 / 1549- 


t414 = 


t548 + 1413* 


t41 5 = 


i0 167 + t542* 


t416 = 


16 * t415; 


t421 = 


-1 12 * t22; 


t422 = 


r 179 * t374' 


t423 = 


16 * i2 171* 


t424 = 


t422 - 1423- 


t425 = 


t542 * t424* 


t426 = 


t421 + 1425; 


t427 = 


t426 / 1549; 


t428 = 


t416 + t427; 


i 185 = 


= 0; 



20 



25 



30 



Perspective preloop basic block 118 

t744 = s_221 12; 
t542 = 2 * i0_205; 
t543 = t542 + du0_213; 
t544 = t744 * t543; 
t546 = 2 * j0_206; 
t547 = t546 + dv0_214; 
t548 = t744 * t547; 
t550 = 2*il_207; 
t551 =t550 + dul_215; 
t552 = t551 +du0_213; 
t553 = t744 * t552; 
t555 = 2 * jl_208; 
t556 = t555 + dvl_216; 
t557 = t556 + dv0_214; 
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10 



15 



20 



25 



30 



t558 
t560 
t561 
t562 
t563 
t565 
t566 
t567 
t568 
1570 
t571 
t572 
t573 
t574 
t575 
t577 
t578 
t579 
t580 
t581 
t582 
t745 
t28 = 
t34 = 
t746 
t587 
t747 
t748 
t29- 
t35 = 
t592 
t593 
t749 
t594 
115615Sv2 



= t744 * t557; 
= 2 * i2_209; 
= t560 + du2_217; 
= t561 +du0_213; 
= t744 * t562; 
= 2 * j2_210; 
= t565 + dv2_218; 
= t566 + dv0_214; 
= t744 * t567; 
= 2 * i3_211; 
= t570 + du3_219 
= t571 +du2_217 
= t572 + dul_215 
= t573-du0_213 
= t744 * t574; 
= 2 * j3_212; 
= t577 + dv3_220 
= t578 + dv2_218 
= t579 + dvl_216 
= t580 + dv0_214 
= t744 * t581; 
= t544-t553; 
t745 - 1563; 
t28 + 1575; 
= t568 - 1582; 
= t34 * t746; 
= t563 - 1575; 
= t548-t558; 
t748 - 1568; 
t29 + 1582; 
= t747 * t35; 
= t587 - 1592; 
= 144; 

= t593 * t749; 
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t750 = t553 - 1575* 




t599 = t35 * t750* 




t751 = t558 - t582- 




t604 = t751 * t34* 


5 


t605 = t599 - t604- 




t752 = 176* 




t606 = t605 * t752- 




t609 = t750 * t746- 




t612 = t747 * t751- 


10 


t613 = t609 - t612* 




t614 = t553 - t544- 




t615 = t613 * t614; 




t616 = t615 * t749* 




t617 = t594 * t553* 


1 s 


tfil R = t 61 6 + t61 7- 




t619 = tS63 - tS44- 




t620 = t61 3 * t619- 




t621 = t620 * t7S2- 




t622 = t606 * t563- 


20 


t623 = t621 + t622- 




t624 = t613 * t544- 




t625 = t624 * t7S2* 




t626 = t625 * t749- 

WJ^.\J IvZ. J I / ~7 5 




t627 = t558 - t548* 


25 


t628 = t613 * t627* 




t629 = t628 * t749* 




t630 = t594 * t558- 




t631 = t629 + t630* 




t632 = tS6R — tS4R- 




t633 = t61 3 * t632* 




to34 — to33 * t/52; 




t635 = t606 * t568; 




t636 = t634 + t635; 




t637 = t613 *t548; 
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t638 = t637 * t752; 
t639 = t638 * t749; 
i_228 = 0; 

At 120 in Fig. 1 the basic blocks are extracted from the CFGs 103 and 104 of Fig. 2 A 
5 and B developed by the Lance utility 101 . The exemplary Affine and Perspective basic 

blocks are shown in Fig. 1 being input to the Lance compiler utility running its "Show DFG" 
operation to develop an Affine data flow graph and a Perspective data flow graph at outputs 
122 and 123. The extraction of the basic blocks at 120 in Fig. 1 may be effected manually or 
by a simple program discarding low instruction count basic blocks prior to passing them 

10 along to the Lance compiler 101 for the production of the data flow graphs. The data flow 

graphs out of the Lance compiler are input to an operation by which pairs of data flow graphs 
are selected as candidates for development of a largest common subgraph. 

Remembering that many data flow graphs may have been produced from the 
multimedia application initially input to the Lance compiler utility 101, it is at this point that 

1 5 a selection process identifies the Affine and Perspective as good candidates for pairing to 
develop the desired largest common subgraph. That selection process is indicated at 124 in 
Fig. 1 . Data flow graphs of the kind selected are shown in Figs. 4 A and B. These are 
directed acyclic graphs (DAGs). This is to say, as indicated by the arrows in Figs. 4 A and B, 
the operations move in a single direction from top to bottom and do not loop back. The 

20 rectangles of Fig. 4 A represent the instructions of the Affine preloop basic block 106 and the 
rectangles of Fig. 4 B represent the instructions of the Perspective preloop basic block 118. 

Again visually, using the color coding indicated in Figs. 4 A and 4 B as currently 
implemented, these data flow graphs are compared for similarity and two or more are chosen. 
Again a simple program may be implemented for the same purpose as will be apparent. See 

25 the color key of Figs. 4 A and 4 B - the instructions contained in the individual rectangles of 
the data flow graphs like those of Figs. 4 A and 4 B are add (+), divide (/), multiply (*), 
subtract (-) and memory transaction (the last not present in Figs. 4 A and 4 B). To make it 
visually easier to identify similarities, then, in the present, human visual implementation, 
each type of instruction is identically color-coded blue, red, green, etc. In the example of Fig. 

30 1, the data flow graphs for the Affine and Perspective preloop basic blocks have been chosen 
and are input at 126 and 127 to a routine 129 to identify the Largest Common Subgraph 
(LCSG) shared by the two data flow graphs. One approach to identification of the LCSG 
based on finding seed basic blocks and building on these is discussed below under "Proposed 
Approach." 
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Description of LCSG Scheduling for Shared Resources 

Fig. 5 illustrates the largest common subgraph developed from the Affine and 
Perspective preloop basic blocks. At 131 and 133 of Fig. 1, ASAP scheduling of the LCSG 
takes place in known fashion iteratively with the LCSG individually and with the LCSG 
5 inserted into the Data Flow Graphs until the most efficient scheduling of the Data Flow 
Graphs is realized at block 133. 

ASAP scheduling is a known technique. In the LCSG of Fig. 5 ASAP scheduling is 
accomplished by moving elements representing instructions upward where possible to permit 
their use more quickly and perhaps more quickly freeing a circuit component that effects that 

10 instruction for a further use. From the LCSG of Fig. 5 it will be seen that 33 instructions 

from each of the Affine and Perspective codes have now been identified to be implemented in 
hardware and shared by the two multimedia operations represented by the Affine and 
Perspective CFGs originally developed at 101. The same will be done for other Control Flow 
Graphs representing other portions of the multimedia application introduced at the compiler 

15 101 . Instructions not covered by a LCSG will be accomplished by general purpose 
processing look up tables (LUTs) on the ultimate chip. The output from the ASAP 
scheduling that occurs at 131 in Fig. 1 is an intermediate result or graph at 132. Affine and 
Perspective DAGs with ASAP scheduling and the inclusion of the common LCSG are shown 
in Figs. 6 A and 6 B. In Fig. 6 A, for example, it will be seen that the instruction A 1 has 

20 been moved up from line 2 in Fig. 5's unscheduled LCSG to the same line (line 1) as the 

instruction V. Likewise the instruction A 3 has been moved up so that there are now four like 
instructions in the first line of the LCSG portion of the Fig. 6 A Affine DAG requiring four 
processing elements. In the second line instruction A 2 and A 4 have been moved up and are 
now at the same line as instruction U and instruction X. These are all like instructions, so 

25 four like processing elements will be required to simultaneously run the four instructions. 
However, the LCSG may, but will not necessarily include, a lesser number of circuit 
elements of a kind in a single line. The resistors Ri, R2... in Figs. 6 A and 6 B are inserted 
delays between executions of instructions. 



30 of Figs. 6 A and 6B. At blocks 135 and 136 data paths are defined for each of these and at 
block 138 data paths are combined to produce at 140 the code for a circuit Z in VHDL. That 
code for the combined preloop basic blocks of Affine and Perspective follows: 
preloop common.vhd 
library ieee; 
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use ieee.std_logic_l 164.all; 
use ieee.std_logic_arith.all; 
use ieee.std_logic_unsigned.all; 
use ieee.numeric_std.all; 
5 entity preloop_common_datapath is 
port( 

— inputs 

ip l, ip_2, ip_3, ip_4, ip_5, ip_6, ip_7, ip_8, ip_9, ip_10, ip_l 1 :in std_logic vector(15 
downto 0); 
1 0 — constant inputs 

constant_l, constant_2, constant_3, constant_4, constant_5, constant_6, constant_7, 
constant_8, constant_9 9 constantlO, constant_l 1, constant_12, constant_13, constant_14, 
constant_15, constant_16, 

constant_17, constant_18, constant_19, constant_20, constant_21, constant_22 : in 
1 5 std_logic_vector( 1 5 downto 0); 

— 2 input mux select lines 

sel_l 5 sel_2, sel_l 1, sel_12, sel_21, sel_22, sel_23, sel_24, sel_25, sel_26, 
sel_27, sel_28, sel_29, sel_30 : in stdlogic; 

— 3 input mux select lines 

20 sel_3, sel_4 9 sel_5, sel_6, sel_7, sel_8, sel_9, sel_10, sel_13, sel_14, sel_15, 
sel_16, sel_17, sel_18, sel_19, sel_20 : in std_logic_vector(l downto 0); 
~ enable signals for tri-state buffers at output of muxs 

en_l, en_2, en_3, en_4, en_5, en_6, en_7, en_8, en_9, en_10, en_l 1, en_12, en_13, en_14, 
en_15, 

25 en_16, en_17, en_18, en_19, en_20, en_21, en_22, en_23, en_24, en_25, en_26, en_27, 
en_28, 

en_29, en_30 : in std logic; 

— output signals 

op l, op_2, opj, op_4, op_5, op_6 : out std_logic_vector(15 downto 0); 
30 elk : in std_logic ; 
rst :in std_logic 



); 

end preloopcommondatapath ; 

architecture arch_preloop_common_datapath of preloop common datapath is 
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component xcv2_multl6xl6s is 
Port( 

a : in std_logic_vector(15 downto 0); 
b : in std_logic_vector(15 downto 0); 
5 elk : in std_logic; 

prod : out std_logic_vector(3 1 downto 0) 

); 

end component; 

— these muxs are those controlling inputs to adders and multipliers 

10 signal muxlout, mux_2out, mux_3out, mux_4out, mux_5out, mux_6out : std _logic_vector( 
1 5 downto 0); 

signal mux_7out, mux_8out, mux_9out, mux_10out, mux l lout, mux_12out: 
std_logic_vector( 15 downto 0); 

signal mux_13out, mux_14out, mux_15out, mux_16out, mux_17out, 
15 mux_18out:std_logicvector( 15 downto 0); 

signal mux_19out, mux_20out : std_logic_vector( 15 downto 0); 

— these muxs are those controlling register delay paths that differentiate 

— affine and perspective transform configurations 

signal mux_21out, mux_22out, mux_23out, mux_24out, mux_25out, mux_26out, 
20 mux_27out, mux_28out, mux_29out, mux_30out : std_logic_vector(15 downto 0); 

— these signals capture the 32 bit outputs from multipliers and are 

— fed to filters that remove the 3 1 - 16 MSBs 

signal temp i, temp_2, temp_3, temp_4, temp_5, temp_6, temp_7, temp_8, temp_9, 

temp_10: std_logic_vector(3 1 downto 0); 
25 — these signals get the 16 bit outputs from the temp signals and feed to register inputs 

signal input_reg_l, input_reg_12, input_reg_14, input_reg_19, input_reg_25, input_reg_28, 

input_reg_39, input_reg__4 1 , input_reg_6, input_reg__33, input_reg_20, input_reg_15, 

input_reg_26, input_reg_29, input reg_22 : std_logic_vector(15 downto 0); 

~ these signals are the outputs of tri_state buffers present after the muxs 
30 — which control the exit points of the adjusted delayed paths 

signal tri_state21, tri_state22, tri_state23, tri_state24, tri_state25, tri_state26, tri_state27, 

tri_state28, tri_state29, tri_state30 : std_logic_vector(15 downto 0); 

signal reg_l, reg_2, reg_3, reg_4, reg_5, reg_6, reg_7, reg_8, reg_9, reg_10, 

reg_12, reg_14, reg_15, reg_19, reg__20, 
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reg_22, reg_23, reg_24, reg_25, reg_26, reg_28, reg_29, reg_33, 
reg_34, reg_35, reg_36, reg_37, reg_39, 

reg_41, reg_42, reg_43, reg_44, reg_45, reg_46, reg_47, reg_48, reg_49, reg_50, 
reg_51, reg_52, reg_53, reg_54, reg_55, reg_56, reg_57, reg_58, reg_59, reg_60, 
5 reg_61, reg_62, reg_63, reg_64, reg_65, reg_66, reg_67, reg_68, reg_69, reg_70, 
reg_71, reg_72, reg_73, reg_74, reg_75, reg_76, reg_77, reg_78, reg_79, reg_80, 
reg_81 : std_logic_vector(15 downto 0); 
begin 

— the following are the multiplexers controlling the inputs to multipliers 
1 0 mux_l out <= reg_20 when sel_l = '0' else tri_state22; 
mux_2out <= reg_24 when sel_2= '0' else constant_2; 
with sel 3 select mux 3out <= 



15 



ip_3 when "00", 
reg_15 when "01", 
tri_state23 when "10", 
(others =>'Z % ) when others; 



with sel 4 select mux 4out <= 



20 



constant_3 when "00", 
reg_24 when "OP, 
constant_4 when "10", 
(others =>'Z') when others; 



with sel 5 select mux 5out <= 



25 



ip_4 when "00", 
reg_20 when "01", 
tri_state24 when "10", 
(others =>'Z % ) when others; 



with sel 6 select mux 6out <= 



30 



constant_5 when "00", 
reg_23 when "01", 
constant_6 when "10", 
(others => , Z') when others; 



with sel 7 select mux 7out <= 



ip_6 when "00", 
reg_23 when "01", 
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tri_state25 when "10", 

(others => % Z X ) when others; 
with sel_8 select mux_8out <= 

constant_7 when "00", 
5 reg_23 when "01", 

constant_8 when "10", 

(others => , Z I ) when others; 
with sel_9 select mux_9out <= 

ip_7 when "00", 
10 reg_24 when "01", 

tri_state26 when "10", 

(others =>'Z') when others; 
with sel_10 select mux_10out <= 

constant_9 when "00", 
15 reg_29 when "01", 

constantJO when "10", 

(others =>'Z f ) when others; 
mux l lout <= reg_24 when sel_l 1= '0' else tri_state27; 
mux_12out <= reg_26 when sel_12= '0' else constant l 1; 
20 — the following are the multiplexers controlling the input to adders 
with sel l 3 select mux_13out <= 

reg_19when "00", 

ip_10 when "01", 

tri_state21 when "10", 
25 (others =>'Z') when others; 

with sel_14 select mux_14out <= 

constant_15 when "00", 

constant_16 when "01", 

reg_12 when "10", 
30 (others => f Z') when others; 

with sel l 5 select mux_15out <= 

reg_14 when "00", 

reg_15 when "01", 

tri_state29 when "10", 
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(others =>'Z') when others; 
with sel_l 6 select mux l 6out <= 

constant_17 when "00", 

constant_18 when "01", 
5 reg_14 when "10", 

(others =>'Z') when others; 
with sel l 7 select mux_17out <- 

reg_25 when "00", 

ip_ll when "01", 
10 reg_39 when"10", 

(others => ! Z f ) when others; 
with sel_18 select mux_18out <= 

constant_19 when "00", 

constant_20 when "01", 
15 tri_state28 when "10", 

(others => % Z % ) when others; 
with sel l 9 select mux_19out <= 

reg_28 when "00", 

reg_29 when "01", 
20 reg_28 when"10", 

(others =>'Z') when others; 
with sel_20 select mux_20out <= 

constant_21 when "00", 

constant_22 when "01", 
25 tri_state30 when "10", 

(others => % Z') when others; 
— the following are the statements implementing the multipliers 
multp instl : xcv2_multl6xl6s 
port map ( ip_l, constant_l, elk, temp_l); 
30 input_reg_l <= temp_l(15 down to 0); 
multp_inst2 : xcv2_multl6xl6s 
port map ( mux lout, mux_2out, elk, temp_2); 
input_reg_12 <= temp_2(15 downto 0); 
multp_inst3 : xcv2_multl6xl6s 
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port map ( mux_3out, mux_4out, elk, temp_3); 

input_reg_14 <= temp_3(15 down to 0); 

multp_inst4 : xcv2_multl6xl6s 

port map ( mux Sout, mux_6out, elk, temp_4); 
5 inputregl 9 <= temp_4(l 5 down to 0); 

multp_inst5 : xcv2_multl6x!6s 

port map ( mux_7out, mux 8out, elk, temp_5); 

input_reg_25 <= temp_5(15 downto 0); 

multp_inst6 : xcv2_multl6xl6s 
10 port map ( mux_9out, mux_10out, elk, temp_6); 

input_reg_28 <= temp_6(15 downto 0); 

multp_inst7 : xcv2_multl6xl6s 

port map ( mux 1 lout, mux_12out, elk, temp_7); 

input_reg_39 <= temp_7(15 downto 0); 
15 multp inst8 : xcv2_multl6xl6s 

port map ( ip_9, constant_12, elk, temp_8); 

input reg_41 <= temp_8(15 downto 0); 

multp_inst9 : xcv2_multl6xl6s 

port map ( ip_2, constant_13, elk, temp_9); 
20 input__reg_6 <= temp_9(15 downto 0); 

multp instlO : xcv2_multl6xl6s 

port map ( ip_8, constant_14, elk, temp lO); 

input_reg_33 <= temp_10(15 downto 0); 

— the following are the statements implementing the adders 
25 input_reg_20 <= mux l 3out + mux_14out; 

input_reg_15 <= mux_l 5out + mux_16out; 
input_reg_26 <= mux_l 7out + mux_18out; 
input_reg_29 <= mux_19out + mux_20out; 

— the following are the statements implementing the divide / shifter 

30 -input_reg_22 <= ip_5 and M 001 1111111111111";-- performing srl by 2 

input_reg_22 <= "00" & ip_5(15 downto 2); -SRL 3 ; - performing srl by 2 

— the following are the statements implementing register transfers 

— sel line here being '1' represents state machine for Perspective Transform 

— enable line of the tristate buffers here is T when either Affine or Perspective State machine 
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— selects the associated mux. 

mux_21out <= reg_l when sel_21= T else reg_5; 

tri_state21 <= mux_21out when en_21 = T else (others => 'Z'); 

mux_22out <= reg_12 when sel_22 = T else reg_51; 
5 tri_state22 <= mux_22out when en_22 = T else (others => 'Z'); 

mux_23out <= reg_14 when sel_23 = T else reg_57; 

tri_state23 <= mux_23out when en_23 = T else (others => 'Z'); 

mux_24out <= reg_19 when sel_24 = T else reg_63; 

tri_state24 <= mux_24out when en_24 = T else (others => 'Z'); 
10 mux_25out <= reg_25 when sel_25 = T else reg_69; 

tri_state25 <= mux_25out when en_25 = '1' else (others => 'Z'); 

mux_26out <= reg_28 when sel_26 = T else reg_75; 

tri_state26 <= mux_26out when en_26 = T else (others => 'Z'); 

mux_27out <= reg_39 when sel_27 = '1' else reg_81 ; 
1 5 tri_state27 <= mux_27out when en_27 = T else (others => 'Z'); 

mux_28out <= reg_41 when sel_28 = '0' else reg_45; 

tri_state28 <= mux_28out when en_28 = T else (others => f Z'); 

mux_29out <= reg_6 when sel_29 = '0* else reg lO; 

tri_state29 <= mux_29out when en_29 = T else (others => 'Z'); 
20 mux_30out <= reg_33 when sel_30 = '0* else reg_37; 

tri_state30 <= mux_30out when en_30 = T else (others => , Z'); 

reg_pr :process (elk 

,rst,reg_80,input_reg_l ,reg_l ,reg_2 5 reg_3,reg_4,input_reg_l 2,reg_l 2,reg_46,reg_52,reg_53, 
reg_54, 

25 reg_47,reg_48,reg_49,reg_50,input_reg_14,reg_14,reg_55 ? reg_56,input_reg_19, 
reg_19,reg_58,reg_59,reg_60 > reg_61,reg_62,input_reg_25,reg_25,reg_64, 
reg_65 ,reg_66 > reg_67,reg_68,input_reg __28,reg_28 ,reg_70,reg_7 1 ,reg_72, 
reg_73,reg_74,input_reg_39,reg_39 J reg_76,reg_77 5 reg_78 5 reg__79, 
input_reg_4 1 ,reg_4 1 ,reg_42,reg_43,reg_44,input_reg_6,reg_6, 

3 0 reg_7 ,reg_8 ,reg_9,input_reg_3 3 ,reg_3 3 ,reg_34,reg_3 5 ,reg_3 6, 

input_reg_15,input_reg_20,input_reg_22,input_reg_26 5 input_reg_29, 
reg_22,reg_23) 

begin 

if(rst=T) then 
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reg_K=(others =>'0'); 
reg_2<=(others =>'0') ; 
reg_3<=(others =>'0') ; 
reg_4<=(others =>'0*) ; 
5 reg_5<=(others=> , 0') ; 

reg_6<=(others =>'0') ; 

reg_7<=(others =>'0'); 
reg_8<=(others =>*0*) ; 
reg__9<=(others =>*<)•) ; 
10 reg_ 1 0<=(others =>'0') ; 

reg_12<=(others =>'0') ; 

reg_14<=(others =>'0') ; 
reg_15<=(others =>'0') ; 
reg_19<=(others =>'0'); 
1 5 reg_20<=(others =>'0') ; 

reg_22<=(others =>'0') ; 
reg_23<=(others=>'0') ; 
reg_24<=(others =>'0') ; 
reg_25<=(others =>'0'); 
20 reg_26<=(others =>'0') ; 

reg_28<=(others ^'O') ; 
reg_29<=(others=>'0') ; 
reg_33<=(others =>■()•) ; 
reg_34<=(others =>'0') ; 
25 reg_35<=(others=>'0') ; 

reg_36<=(others ^'O') ; 

reg_37<=(others =>'0'); 
reg_39<=(others => , 0') ; 
reg_41<=(others=> , 0 i ) ; 
30 reg_42<=(others ^'O 1 ) ; 

reg_43<=(others =>'0'); 
reg_44<=(others =>'0') 
reg_45<=(others ^o'O') 
reg_46<=(others =>'0') : 
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reg_47<=(others=>'0') ; 

reg_48<=(others =>«0') ; 
reg_49<=(others => , 0'); 

reg_50<=(others =>'0') ; 
5 reg_5 1 <=(others =>'0') ; 

reg_52<=(others =>'0') ; 

reg_53<=(others=>'0*) ; 

reg_54<=(others ^'O 1 ) ; 
reg_55<=(others ^'O'); 
10 reg_56<=(others =>'0') ; 

reg_57<=(others =>'0') ; 

reg_58<=(others ^O') ; 

reg_59<=(others=> , 0') ; 

reg_60<=(others =>'0*) ; 
1 5 reg_6 1 <=(others =>*0'); 

reg_62<=(others =>'0') ; 

reg_63<=(others =>'0') ; 

reg_64<=(others =>'0') ; 

reg_65<=(others=>'0') ; 
20 reg_66<=(others ^'O') ; 

reg_67<=(others =>'0'); 

reg_68<=(others =>'0') ; 

reg_69<=(others =>'0') ; 

reg_70<=(others =>'0') ; 
25 reg_7 1 <=(others=>'0') ; 

reg_72<=(others =>'0') ; 

reg_73<=(others =>'0') ; 
reg_74<=(others ^'O'); 

reg_75<=(others =>'0') ; 
30 reg_76<=(others ^'O') ; 

reg_77<=(others =>'0') ; 

reg_78<=(others=>'0*) ; 

reg_79<=(others =>'0') ; 
reg_80<=(others =>'0'); 
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reg_8K=(others =>'0') ; 

elsif (rising_edge(clk))then 

reg l <= input_reg_l; 

reg_2 <=reg_l; 

reg_3 <= reg_2; 
reg_4 <= reg_3; 

reg_5 <= reg_4; 

reg_12 <= input_reg_12; 

reg_46 <= reg_12; 

reg_47 <= reg_46; 

reg_48 <= reg_47; 

reg_49 <= reg_48; 

reg_50 <= reg_49; 

reg_51 <= reg_50; 

reg_14 <= input _reg_14; 

reg_52 <= reg_14; 

reg_53 <= reg_52; 

reg_54 <= reg_53; 

reg_55 <= reg_54; 

reg_56 <= reg_55; 

reg_57 <= reg_56; 

reg_19 <= input_reg_19; 

reg_58 <= reg_19; 

reg_59 <= reg_58; 

reg_60 <= reg_59; 

reg_61 <= reg_60; 

reg_62 <= reg_61; 

reg_63 <= reg_62; 

reg_25 <= input _reg_25; 

reg_64 <= reg_25; 

reg_65 <= reg_64; 

reg_66 <= reg_65; 

reg_67 <= reg_66; 

reg_68 <= reg_67; 
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reg_69 < 
reg_28 < 
reg_70 < 
reg_71 < 
reg_72 < 
reg_73 < 
reg_74 < : 
reg_75 < : 
reg_39< : 
reg_76 < : 
reg_77 < 
reg_78 < : 
reg_79 < : 
reg_80 <= 
reg_81 < : 
reg_41 < : 
reg_42 <= 
reg_43 < : 
reg_44 <= 
reg_45 <= 
reg_6 <= 
reg_7 <= 
reg_8 <= 
reg_9 <= 
reg_10 < : 
reg_33 < 
reg_34 < : 
reg_35 < 
reg_36 < : 
reg_37< : 
reg_20 < : 
reg_15 < : 
reg_26 < : 
reg_29 <= 



= reg_68; 
•= input_reg_28; 
reg_28; 
reg_70; 
reg_71; 
= reg_72; 
= reg_73; 
= reg_74; 
= input_reg_39; 
= reg_39; 
= reg_76; 
= reg_77; 
= reg_78; 
= reg_79; 
= reg_80; 
= input_reg_4 1 ; 
= reg_4 1 ; 
= reg_42; 
= reg_43; 
= reg_44; 
input_reg_6; 
reg_6; 
reg_7; 
reg_8; 
= reg_9; 
= input_reg_33; 
= reg_33; 
= reg_34 
= reg_35 
= reg_36 
= input_reg_20; 
- input_reg_15 
= input_reg_26; 
= input_reg_29: 
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reg_22 <= input_reg_22; 
reg_23 <= reg_22; 
reg_24 <= reg_23; 

end if ; 
end process reg_pr; 
op_3 <= reg_19; 
op_4 <= reg_25; 
°P_1 <= re g_20; 
op_2 <= reg_15; 
op_6 <= reg_26; 
op_5 <= reg_29; 
end architecture; 

Proposed Approach for Arriving at Largest Common Subgraph 

Returning to LCSG development, in the following approaches, an exemplary 
preferred embodiment of the invention starts with control data flow graphs, CDFGs, 
representing the entire application and which have been subjected to zone identification, 
parallelization and loop unrolling. The zones / Control Points Embedded Zones (CPEZ) that 
can be suitable candidates for reconfiguration will be tested for configurable components 
through the following approaches. Note: Each Zone / CPEZ will be represented as a graph. 
Seed selection: 

This approach is to find seed basic blocks and proceed on the CFG to grow these 
seeds. Note that all basic blocks which have outgoing edges whose destination basic block's 
first instruction line number is less than or equal to the line number of the first instruction of 
the source basic block, then those outgoing edges are loop back edges. 

For example, if, in Fig. 7, basic block Y's (BBy's) first instruction line number (as 
extracted from the *.ir.c file) is <= equivalent line numbers of basic blocks X or Y, then that 
edge is a loop-back edge (e y . x ) and BBx will be the start of the loop and BBy will be the seed. 
Since C/C++ are sequential languages the Lance compiler does not build loop in any other 
manner that is erroneous. 

In this approach, the seed is a basic block that lies inside a loop because the loop is 
done over and over. This process can result in 3 types of loops: 



(i) A single nested level loop with only 1 basic block as shown in Fig. 8, 
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(ii) A single nested level loop with > 1 basic block as shown in Figs. 9 A and B, Z is 
not considered a loop in Fig. 9 A, and 

(iii) Multi-level nested loop as shown in Fig. 10. 

To proceed further we will consider as seeds only basic blocks of class X as in types 
5 (ii) and (iii). This step is a simple construct to start off and yet allows the growth of the 

constructs to include multiple level nested loops, without one growing construct overlapping 
another growing construct/cluster. 

The next step is to identify all basic blocks that come under the control umbrella of X 
and Y. All such basic blocks lie between the linked list entries of V i.e. G(E,V) of X and Y. 
10 These blocks are classified into 3 categories (i) Decision (ii) Merge (iii) Pass as shown for 
example in Fig. 1 1 . 

The same block might be included in both Decision and Merge classes. Therefore 
the number of blocks in this umbrella under (a, j) <= (Decision + Merge + Pass). This feature 
vector is one of the vectors used to quickly estimate the similarity of clusters. 
15 Another feature vector will be the vector of operation type count for blocks in the 

Decision, Merge and Pass classes. 
Example: 

Merge (c, e, j) + * V / 

c= 5 3 2 1 

20 e= 2 0 1 0 

j = 0 3 0 0 

Total = (7,6,3, , 1) 

These steps should be used to form candidate clusters from the CFG that can be 
classified as similar / reconfigurable. This result could vary based on programmer's skill. 
25 Highly skilled programmers could lead to faster grouping because of encompassing repeated 
versions of a complex construct into a function and perform repeated function calls. 

Finer comparisons for performing the extraction of the largest common sub-graph, is 
carried out on this group. 

Identifying the Largest Common Sub-graph or Common set of Sub-graphs between 
30 two candidate Data Flow Graphs representing a Basic Block each. 

Each edge in a DFG is represented by a pair of nodes (Source and Destination). Each 
node represents an operation such as add (+), multiply (*), divide (/) etc. All the edges are 
represented by a doubly linked list as part of the graph representation G(V,E). These edges 
are now sorted based on the following criteria into several bins. 
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The criteria for sorting is based on the fact that an edge consists of two basic 
elements, Source Operation (SO) and Destination Operation (DO). A graph like that of Fig. 
12 is prepared. This plots operations a, b and c of the nodes against cycles of the process 
graphed. Operations a, b and c could be (and often will be) add (+), multiply (*) and divide 
5 (/). In the example shown in Fig. 12, source operation 'a 5 has a lower rank than 'b' and c c\ If 
the SO of the edges are the same, then their DO are compared. The same rule applies: the DO 
with the lower rank, is placed to the left. In this manner, the string is sorted. Say for example 
a sorted string of a first, candidate graph (graph number 1) is: 



10 Now these pairs of alphabetic designators will be placed into bins. In order to place them the 
first or the left most pair (aa in our example) is assumed to be the head of the queue. It is 
placed in the first bin. Then all the following elements in the queue are compared with the 
head, till a mismatch is obtained. If a match occurs then, that pair is placed in the same bin as 
the head. Now the first mismatched pair is designated as new head of the queue. This is now 

15 placed in a new bin and the process is followed till all elements are in a set of bins as shown 
in Fig. 12 A. 

The next step is to perform a similar (but not exactly the same) process for the graph 
that needs to be compared with the candidate graph, graph number 1 . Consider a second 
graph, graph number 2 as shown in Fig. 13. (In graph 2 flow is left to right rather than top to 
20 bottom.) 

This graph is converted to a string format in the same manner as graph #1 and this 
string, as shown below needs to be placed into a new set of bins. 



25 compared to the element type in the first bin of the old set(aa) [This is termed as the reference 
bin]. If it checks to be the same, then the first bin of the new set is created and all elements up 
to the first mismatch are placed in this bin. Then the reference bin is termed as checked. Now 



mismatch, then the comparison is done with the next unchecked bin and so on, until the SO 
30 of the element type is different from the SO of the element type in the reference bin. At this 
point, a comparison of all successive element pairs in the current queue are compared with 
the head, till a mismatch is met. Then the matched elements are eliminated. 



aa, aa, ac, ba, ba, bb, be, cb, cc 



aa, ab; ab, ba, ba, bb, bb, be, cb, cc 

This is done by assigning the leftmost element in the queue to be the head. It is first 



the new head type is compared to the first unchecked bin of the reference set. If there is a 
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But in case, a match is found between the head of queue and a reference bin, then a 
new bin in the current set is created and suitably populated. The corresponding reference bin 
is checked and all previously / predecessor unchecked reference set bins are eliminated. 

By this approach, we are eliminating comparison between unnecessary edges in the 
5 graphs. Now a new set of bins for graph 2 is obtained as shown (Fig. 13 A). Thus the edges 
in a Data Flow Graph, representing a Basic Block, are arranged into bins as described above. 
Only note that when it said that a bin should be eliminated if its corresponding type is not 
found in the previous pair, then what is meant is that the bin should be marked for 
elimination. Thus one will have a pair of bin sequences, in which some bins might have been 
10 marked as 'eliminated' type. Consider any such bin and track all edges connected to edges in 
that bin. If any of these connected edges are isolated edges (i.e. all their connected edges => 
predecessors + siblings + companions + successors are marked as 'eliminated') then mark 
them as 'eliminated'. This is illustrated in Figs. 14 A and B. 

Now for all the remaining 'un-eliminated' edges, quadruple associativity 
1 5 information is obtained (Predecessor, Siblings, Companions, and Successors). At this point 
measure the associativity counts for all edges in a bin pair. 

For example, if we have 3 bins in each graph, say Add-Divide, Divide-Multiply and 
Add-Multiply, then redistribute edges in each bin of each graph, into the corresponding 
associativity columns. This will result in the tables (called Associativity-Bin matrices) shown 
20 below, where 'x' represents edges belonging to a particular associativity number in a bin. 
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Associativity Bin Matrix 1 



Associativity Bin Matrix 2 



Gl 


5 


4 


3 


2 


1 


+/ 






Z 


A 




/* 


P 






T 




+* 






E 


F 





G2 


5 


4 


3 


2 


1 


+/ 




B 


Q 






/* 




R 






U 


+* 








S 


X 



The following pseudo code in C describes the matching or the discovery of the largest 

common sub-graph or sets of common subgraphs between the two candidate DAGs using the 

Associativity-Bin Matrices. 

************************** Pseudo c code 

begin***************************** 
begin********************************** 

Given 2 sorted Directed Acyclic Graphs Gl and G2 the matrix form such that 
height of both matrixes = height, and 
width of graph 1 = width_Gl 
width of graph 2 = width_G2 
As an example, 

Graph 1 Graph 2 

Associativity Count 

7632 11 5432 



h 
e 
i 

9 
h 
t 



+ / 



+ / 



width of Graph 1 = 4 



widthofGraph2 = 5 



here x marks those row, column intersections where edges of the graph are distributed into 
and an x represents a Primary Group of Edges (PGE) or Secondary Group of Edges (SGE) 



^^^c^c^;^;^;^:^;^;^^^^^^^^^^^^^^ * *C/Omment 



mainO 
{ 



initialize i = height; 
initialize k = width_G2; 

for (j = width_G2; j<= 1 OR Gl(i j)=Null; j~) 
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{ 

for (i = height; i<= 1 OR Gl(ij)=Null; i») 
{ 

while (G2(i,k)=Null) 

5 { 

k++; 

if(k>width_G2) 

exit and goto LOC_l ; 

} 

10 /* function call*/ 

compare (Gl(ij).edges, G2(i,k). edges); 
reset value of k to width_G2; 

label: LOC_l 

} 

1 5 reset value of i to height; 

} 

} 

void compare (groupofedgesl, group_ofedges2) 

{ 

20 if (groupofedgesl .#of_edges > group_of_edges2.#of_edges) 

{ 

group of edgesl is Primary_Group_of_Edges or PGE; 
group_of_edges2 is SecondaryGroupofEdges of SGE; 

} 

25 else 

the other way around; 

9|SS|Sj|(S|6J|CJ|Sj|S3|C8|8S|S3|tJ|t3|tS|t8|CJ|CS|CS|CS|l8|CS|{j|tl|Cj|ej|Cj|C ITime Fit 

Assuming that a group of edges (PGE / SGE) is arranged in the data structure 
30 that looks like this: 

Here a, g, etc... are Nodes, 
and a-g, a-k , etc... are Edges. 
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Edges of type div2mul 
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Table 1 

Note that edges in each slot are divided into 2 baskets: 
1) uncovered basket 
5 2) covered basket 

Initially when the graph comparison begins all Associated Edges (Predecessors, Siblings, 
Companions, Successors) in all slots will be in the respective uncovered baskets. But as 
we begin covering edges, those Associated Edges will start filling their respective covered 
baskets ! ! For reasons of simplicity the above example assumes all the Associated Edges 
10 are in their respective uncovered baskets. 

GTlCj ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 5|cj|C3jc9|C5|C3|CS|C3|c 

/* outer for loop */ 

for(prow = 1 ; prow <= PGE.#of_edges; prow-H-) 
15 { 

/* inner for loop */ 

for(srow = 1 ; srow <= SGE.#of_edges; srow-H-) 

{ 

/* function call*/ 

20 Result = Test_for_compatibility(PGE(prow),SGE(srow)); 

if(Result = fail) 
{ 

prow — ; 

} 

25 else /* if Result == pass */ 

{ 
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/* function call */ 
cover(PGE(prow), SGE(srow)); 

exit(l); /* this should exit the inner for loop and continue with 

the outer for loop */ 

5 } 
} 

/* inner for loop */ 

/* outer for loop */ 
10 return(); 
} 

int Testfor_compatibility(PGE(prow),SGE(srow)) 

{ 

if(PGE(prow).candidate_edge.covered_flag = 
1 5 SGE(srow).candidate edge.covered flag) 

{ 

if(PGE(prow)xandidate_edge.Source_node.touched_flag = 

SGE(srow)xandidate_edge.Source_node.touched_flag) 

{ 

20 if(PGE(prow)xandidate_edge.Destination_node.touched_flag == 

SGE(srow)xandidate_edge.Destination_node.touched_flag) 

{ 

if(PGE(prow).covered_count == SGE(srow).coveredcount) 
{ 

25 for(column = 1; column <= 4; columnH-K) 

{ 

for(slot = 1; slot <=3 AND 
PGE(prow,column,slot) != null AND 
SGE(srow,column,slot) != null; slot++) 
30 { 

if(PGE(prow,column,slot).covered_count === 
SGE(srow,column,slot).covered_count) 

{ 

return pass; 
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/* this indicates a potential for covering 
to be performed*/ 

else 

return fail; 



} 

} 

else 

10 return fail; 

} 

else 

return fail; 

1 5 else 

return fail; 

} 

else 

return fail; 

20 } 

void cover(PGE(prow), SGE(srow)) 

{ 

if(PGE(prow).candidate_edge.covered_flag != 1) 

{ 

25 PGE(prow).candidate_edgexovered_flag = 1 ; 

SGE(srow).candidate_edge.covered_flag = 1; 
update_flags_and_counts(PGE(prow).candidate_edge, 
S GE(sro w) . candidateedge) ; 

} 

30 for(column = 1; column <= 4, column ++) 

{ 

for(slot = 1; slot <=3 AND PGE(prow,column,slot) != null AND 
SGE(srow,column,slot) != null AND 
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# # 

PGE(prow,column,slot).uncovered_count != null AND 
SGE(srow,column,slot).uncovered_count != null; slot++) 

{ 

/* outer for loop */ 

5 for(pedge = 1; pedge <= PGE(prow,column,slot).uncovered_count; 

pedge++) 
{ 

/* inner for loop */ 
for(sedge = 1 ; sedge <= 
10 SGE(srow,column 5 slot).uncovered_count; sedge++) 

{ 

if(PGE(prow,column,slot,uncovered_basket[pedge]).So 
urce_node.touched_flag = 

SGE(srow,column,slot,uncovered_basket[sedge]).Sourc 
1 5 e_node.touched_flag 

AND 

PGE(prow,column,slot,uncovered_basket[pedge]).Desti 
nation_node.touched_flag == 

SGE(srow J column,slot,uncovered_basket[sedge]).Desti 
20 nationnode.touchedflag) 

{ 

push_this_edge_into_covered_basket 

(PGE(prow,colurnn,slot,uncovered_basket[pedg 

e]). 

25 SGE(srow,column,slot,uncovered_basket[sedge] 

)); 

update_flags_and_counts 

(PGE(prow,column,slot,uncovered_basket[pedg 
e]), 

30 SGE(srow,column,slot,uncovered_basket[sedge] 

)); 

exit(l); 

/* this should exit the inner for loop and 
continue with the outer for loop */ 
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} 

} 

/♦inner for loop */ 

} 

5 /* outer for loop */ 

} 

} 

return (); 

10 void push_this_edge_into_covered_basket (pedge, sedge) 
{ 

/* this does a transfer of the covered edge from the uncovered basket of a slot to the 
covered basket of a slot */ 

1 5 void update_flags_and_counts (edge_from_PGE, edge_from_SGE) 

{ 

/* this does an update on all covered flags of edges 
and on all touched flags of nodes 
and on covered and uncovered counts of all slots 
20 and the total count for candidate edges 

*/ 

} 

**************** **********p seuc j 0 code 
en( j* ****************** ********** 

25 The complexity of this algorithm is estimated to be of the order O (N 5 ), where N 

represents the number of edges in the smaller of the 2 candidate graphs. 

Although this complexity is high, yet when compared to the O (P*N 4 ) complexity 
algorithm proposed by Cicirello at Drexel University, the differences are: 

a. Cicirello's algorithm delivers a large enough common sub-graph, which is 
30 an approximate result. 

b. The proposed algorithm not only derives the largest common sub-graph or 
a large-common sub-graph but also potentially derives other common-sub- 
graphs. All such common sub-graphs result in potential savings when 
implemented as an ASIC computation unit. 
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c. Cicirello's algorithm relies on a random number of attempts (P) to start the 
initial mapping. In the worst case, if all possible mappings are tried, then 
the solution becomes exponential. 
Therefore after subjecting the CFG to the above set of processes, 2 types of entities 
5 are obtained: (i) Basic Blocks with Large Common Sub-graphs & (ii) Basic Blocks without 
any common sub-graphs. For the purpose of scheduling, Basic Blocks that share common 
sub-graphs will be termed as 'Processes' or nodes in the CFGs that share resources. As an 
example 2 DAGs (Affine and Perspective preloop) were analyzed for common 
sub-graphs. The common sub-graph obtained is that shown in the Fig. 5. 
1 0 Architectures of Common Sub-graphs: 

For a common-sub-graph, an ASAP schedule is performed. Although many other 
types of scheduling are possible, here the focus is placed primarily on extracting maximal 
parallelism and hence speeds of execution. The earliest start times of individual nodes, are 
determined by the constraint imposed by the ASAP schedule of the parent graph in which the 
1 5 common sub-graph is being embedded / extracted. 

Since the schedule depends on the parent graph, the same sub-graph has different 
schedules based on the parent graph (Affine transform preloop DAG / Perspective transform 
preloop DAG). In order to derive a single architecture that can be used with minimal changes 
in both instantiations of the common sub-graph, the sharing of resources is performed based 
20 on the instance that requires the larger number of resources. This policy is applied to each 
resource type, individually. For example, the sharing of multiplier nodes in instance 1 
(Affine) can be formed as: 

e | j, b, c | v, g, h | Al, A5, A6 | A3, A7, A8 | y, k, 1 | n, o, p | r 
and the sharing of multiplier nodes in instance 2 (perspective) can be formed as: 
25 e | b, c | v, g, h | Al, A5, A6 | A3, A7, A8 | y, k, 1 | o, p | r | j | n | 

Since the instance 2, requires a greater number of resources, the resource sharing in 
instance 1 is modified to match that of instance 2. 

The same process is followed for the adder nodes and a common sharing is obtained: 

A2, f, d | u, t, i | A4, s, q | x, w, m | 
30 Implementing an architecture for each instance with the common resource sharing 

distribution results in 2 similar architectures (shown in Figs. 15 and 16), which differ 
in the number of delays present on certain paths. 

This problem is overcome by adding multiplexers along paths that have different delays 
while connecting the same source and destination(s). This is shown in Fig. 17. 
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In this research effort, the common architectures are implemented as ASICS in 
VHDL. The regions of the DAGs that are not covered by common architectures are left for 
generic LUT style implementation. For the above example of complex warping applications, 
we have synthesized the common architectures and obtained gate counts based on Xilin's 
5 estimates using the Xilinx Synthesis Tool. We have fiirther translated this architecture onto 
LUTs on a Xilinx Spartan 2E FPGA. Based on well accepted procedures, gate count and bit 
stream estimates for the translated architecture have been obtained [refer to Trenz Electronic 
paper]. These results show the potential savings that can be achieved in 2 modes of 
implementation: (i) A completely LUT based architecture with flexible partial 

10 ^configurability and (ii) An ASIC - LUT based architecture. In type (i) the savings are 

expressed in terms of time taken to perform the redundant reconfiguration (assuming that the 
configuration is performed at the peak possible level of 8 bits in parallel at 50 MHz), over 
one run / execution of the preloop basic block and over an expected run of 30 iterations per 
second (since there are 30 frames per second of video, and the preloop basic block is 

1 5 executed for every frame). In type (ii) the savings are expressed in terms of number of gates 
required to represent the architecture in an ASIC versus the number of gates required to 
represent the architecture in an LUT format of the Spartan 2E processor. In both types, 
significant savings are obtained. 
Overall Scheduling for Circuit Configuring 

20 Once the number of processing units has been chosen, the CDFGs have to be mapped 

onto these units. This involves scheduling, i.e. allocating of tasks to the processing units in 
order to complete execution of all possible paths in the graphs with the least wastage of 
resources but avoiding conflicts due to data and resource dependencies. 

In the graph matching, one can include branch operations to reduce the number of 

25 graphs. This can be done, if one of the paths of a branch operation leads to a very large graph 
compared to the other path, or is a subset of the other path. This still leaves us with the 
problem of conditional task scheduling with loops involved. Since scheduling is applicable to 
many diverse areas of research, in this section all the work done in scheduling is not 
discussed. Instead this focuses on those that are relevant to mapping data flow graphs on 

30 processors, proposes a method most suitable for the purpose of reconfiguration, and compares 
it with contemporary methods. Several researchers have addressed task scheduling and one 
group has also addressed loop scheduling with conditional tasks [57]. A detailed survey of 
data and control dominated scheduling approaches can be found in [58], [59] and [60]. Jha 
[57] addresses scheduling of loops with conditional paths inside them. This is a good 
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approach as it exploits parallelism to a large extent and uses loop unrolling. But the drawback 
is that the control mechanism for having knowledge of 'which iteration's data is being 
processed by which resource 5 is very complicated. This is useful for one or two levels of loop 
unrolling. It is quite useful where the processing units can afford to communicate quite often 
5 with each other and the scheduler. In the present case, the network occupies about 70% of the 
chip area [1] and hence cannot afford to communicate with each other too often. Moreover 
the granularity level of operation between processing elements is beyond a basic block level 
and hence this method is not practical. And within a processing element, since the 
reconfiguration distance (edit distance) is more important, fine scale scheduling is 

10 compromised because the benefits with the use of very fine grain processing units is lost due 
to high configuration load time. [68] paper discusses a 'path based edge activation' scheme. 
This basically means, if for a group of nodes (which must be scheduled onto the same 
processing unit and whose schedules are affected by branch paths occurring at a later stage) 
one knows ahead of time the branch controlling values, then one can at run time prepare all 

1 5 possible optimized list schedules for every possible set of branch controller values. In the 
following simple example shown in Fig. 18, the nodes with cross-hatching need to be 
scheduled on the same processing unit. The branch controlling variable is b which can take 
values of 0 or 1 . In case it takes a 0, one branch path is taken, else the other path is taken. In 
the case where one can know at run time, yet ahead of time of occurrence of the branch paths, 

20 the value of 'b', one can prepare schedules for the 3 cross-hatched nodes and launch either 
one, the moment b's value is known. 

This method is very similar to the partial critical path based method proposed by [69]. 
It involves the use of a hardware scheduler and is quite well suited for our application. But 
one needs to add another constraint to the scheduling: the amount of reconfiguration or the 

25 edit distance. In [69] the authors tackles control task scheduling in 2 ways. The first is partial 
critical path based scheduling, which is discussed above. Although they do not assume that 
the value of the conditional controller is known prior to the evaluation of the branch 
operation. They also propose the use of a branch and bound technique for finding a schedule 
for every possible branch outcome. This is quite exhaustive, but it provides an optimal 

30 schedule. Once all possible schedules have been obtained, the schedules are merged. The 

advantages are that it is optimal, but its has the drawback of being quite complex. It also does 
not consider loop structures. Other papers that discuss scheduling onto multiprocessor 
systems include [70], [71] and [72]. Among other works carried out on static scheduling by 
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([73] and [74]) involve linearization of the data flow graphs. Some others have also taken 
fuzzy approaches [75] and [76]. 
Proposed Approach 

Given a control-data flow graph, one needs to arrive at an optimal schedule for the 
5 entire device. A method is provided to obtain near optimal schedules. This involves a brief 
discussion of the PCP scheduling strategy followed by an enhancement to the current 
approach to arrive at a more optimal schedule. In addition the scheduling involves 
reconfiguration time as additional edges in the CDFG. Ways to handle loops embedded with 
mutually exclusive paths and loops with unknown execution cycles are dealt with as well. 

10 A directed cyclic graph developed by the Lance compiler 101 from source code has 

been used to model the entire application. It is a polar graph (macrograph) with both source 
and sink nodes. The graph can be denoted by G (V, E). V is the list of all processes that need 
to be scheduled. E is the list of all possible interactions between the processes. The processes 
can be of three types: Data, communication and reconfiguration. The edges can be of three 

15 types: unconditional, conditional and reconfiguration. A simple example with no 
reconfiguration and no loops is shown in Fig. 19. 

In the graph of Fig. 19, each of the circles represents a process. Sufficient resources are 
assumed for communication purposes. All the processes have an execution time associated 
with them, which has been shown alongside each circle. If any process is a control-based 

20 process, then the various values to which the condition evaluates are shown on the edges 
emanating from that process circle (e.g. PI 1 evaluates to D, or D . The method may be 
summarized as follows: 



30 This example demonstrates the initialization strategy. It describes how the CDFG is split into 
individual DFGs. Moreover, it also shows the various fields required for each node and edge. 
For the CDFG of Fig. 19, initialization of CDFG data structure and Branching tree proceeds 
as follows: 



25 



in. 



n. 



l. 



Use known Partial Critical Path (PCP) scheduling to determine the delays for each 
possible path of the CDFG and arrange the list of paths in descending order of the 
delays. 

Perform branch and bound based scheduling (which need not be done for every 
path to reduce the complexity). 

Once the final list of all schedules is ready, merge all the schedules by respecting 
data and resource dependencies. 
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Varjndices: var[0] = D; var[l] = C; var[2] = K; 
Assume number of processing elements of type = 1 

Branching tree paths: DCK, DCZ,DCK, DC Z, Z)CK, DCK, D C K, D C K 
Branching tree paths not possible: DCK, DCK , D CK, D C K 
Removing K we get: D C, D C 

Final Branching tree paths: DCK, DC AT, DCK, DC K , DC, D C . 

Tables 2 and 3 are the node and edge lists, respectively, for the CDFG of Fig. 19. Figs. 
20 - 25 are the individual Data Flow Graphs (DFGs) of the CDFG of Fig. 19. 
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Table 2: 
Node list for the CDFG 



Nodejndex exec_time pe_index 

1 3 2 

2 5 1 

3 4 1 

4 3 2 

5 10 2 

6 8 3 

7 8 1 

8 4 3 

9 6 1 

10 5 1 
117 3 

12 6 3 

13 1 1 

14 2 4 

15 5 2 

16 4 3 

17 2 2 







# 


j_var_index 


true_or_false 


is_true_var 


[J 


r l 

[I 


0 


r i 
[] 


r i 
I 1 


0 


[] 


r i 
[] 


0 


{1] 


[0] 


1 


[1] 


[0] 


1 


r 4 t 


[1] 


1 


[1] 


[0] 


1 


[1] 


[1] 


1 


[1] 


[1] 


1 


[] 


[] 


0 


[] 


[] 


0 


[0] 


[1] 


1 


[0] 


[0] 


1 


[0 2] 


[1 1] 


2 


[0 2] 


[1 0] 


2 


[0] 


[1] 


1 


[] 


[] 


0 



Table 3: 
Edge list for the CDFG 



ejndex 


parent_node_id 


child_node_id 


is_control 


variable. 


1 


1 


2 


0 




2 


1 


3 


0 




3 


2 


4 


1 


1 


4 


2 


5 


1 


1 


5 


2 


6 


1 


1 


6 


3 


6 


0 




7 


4 


5 


0 




8 


4 


7 


0 




9 


6 


8 


0 




10 


6 


9 


0 




11 


7 


10 


0 




12 


8 


10 


0 




13 


9 


10 


0 




14 


11 


12 


1 


0 


15 


11 


13 


1 


0 


16 


3 


14 


0 




17 


12 


14 


1 


2 


18 


12 


15 


1 


2 


19 


12 


16 


0 




20 


13 


17 


0 




21 


14 


17 


0 




22 


15 


17 


0 




23 


16 


17 


0 





PCP scheduling is a modified list-based scheduling algorithm. The basic concept in a 
partial Critical Path based scheduling algorithm is that if, as shown in Fig. 26, Processing 
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Elements P A , Pb, Px» Py are all to be mapped onto the same resource say Processor Type 1. 
P A and Pb are in the ready list and a decision needs to be taken as to which will be scheduled 
first. X A and Xb are times of execution for processes in the paths of Pa and Pb respectively, 
but which are not allocated on the Processors of type 1 and also do not share the same type of 
resource. 

If P A is assigned first, then the longest time of execution is decided by the Max (T A + 
X A , T A + Tb + Xb). If Pb is assigned first, then the longest time of execution is decided by 
the Max (Tb + Jcb 5 Tb + T a + ^a). The best schedule is the minimum of the two quantities. 
This is called the partial critical path method because it focuses on the path time of the 
processes beyond those in the ready list. Therefore if X A is larger than Xb, a better schedule is 
obtained if Process A is scheduled first. But this does not consider the resource sharing 
possibility between the processes in the path beyond those in the ready list. A simple example 
(Fig. 27) shows that if T A = 3, Tb = 2, X A = 7,Xb = 5, where in processes in the X A and Xb 
sections share the same resource, say Processor type 2, then scheduling Process A first gives 
a time of 15 and scheduling B first gives a time of 14. But both the critical path and PCP as 
proposed by Pop [69] suggest scheduling A first. 

The difference is because, if the resource constraint of the post ready list processes is 
considered, the best schedule is a min of 2 max quantities: 

Max (T B , X a ) & Max (T A , A, B ). 

Pop [69] uses the heuristic obtained from PCP scheduling to bound the schedules in a 
typical branch and bound algorithm to get to the optimal schedule. But branch and bound 
algorithm is an exponentially complex algorithm in the worst-case. So there is a need for a 
less complex algorithm that can produce near-optimal schedules. From a higher view point of 
scheduling one needs to limit the need for branch and bound scheduling as much as possible. 

Initially, the control variables in the CDFG are extracted. Let cl, c2, ,cn be the 

control variables. Then there will be at most 2 n possible data-flow paths of execution for each 
combination of these control variables from the given CDFG. An ideal aim is to get the 
optimal schedule at compile time for each of these paths. Since the control information is not 
available at compile time, one needs to arrive at an optimal solution for each path with every 
other path in mind. This optimal schedule is arrived at in two stages. First the optimal 
individual schedule for each path is determined. Then each of these optimal schedules is 
modified with the help of other schedules. 
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Stage 1\ There are m=2 n possible Data Flow Graphs (DFG's). For each DFG, the PCP 
scheduling is done. Then, the DFG's are ordered in the decreasing order of their total delays. 
An optimal solution can be obtained by doing branch and bound scheduling for each of these 
PCP scheduled DFG's. But branch and bound is a highly complex algorithm with exponential 
complexity. In this case, this complex operation needs to be done 2 n times, where n is the 
number of control variables. This increases the complexity way beyond control. Hence 
branch and bound is done only when it is essential to do so. Then branch and bound 
scheduling is done for DFG1, which has the largest delay. For DFG2, the PCP delay is 
compared with the branch and bound delay of DFG 1. If the PCP delay is smaller, then the 
PCP scheduling is taken as the optimal schedule for that path. If not, then the branch and 
bound scheduling is done to get the optimal schedule. It is reasonable to do this, as the final 
delay of each DFG after modification is going to be close to the delay of the worst delay path. 
In the same way, the optimal schedule is arrived at for each of the DFG. 

Stage 2: Once the optimal schedule is arrived at, a schedule table is initialized with the 
processes on the rows and the various combinations of control variables on the column. A 
branching tree is also generated, which shows the various control paths. This contains only 
the control information of the CDFG. There exists a column in the schedule table 
corresponding to each path in this branching tree. The branching tree is shown in Fig. 26. 
The path corresponding to the maximum delay is taken and the schedule for that 
corresponding path is taken as the template (DCK'). Now the DCK path is taken and the 
schedule is modified according to that of DCK'. This is done for all the paths. The final 
schedule table obtained will be the table that resides on the processor. 



Generate a DFG Gsub(V,E,CTRL_VARS[I]) which is a sub-graph ofG(V t E). Only the 
nodes and edges in the control flow corresponding to the current combination of 
CTRL VARS are included in this sub-graph. 

Generate the PCP schedule of Gi. Let the schedule be PCP_sched[I] and the delay be 
PCP_delay[I]. 



The pseudo code of this process is summarized here. 



Algorithm: 



Task schedule (G(V,E), CTRL_ VARSfNJ, PE = {PE1.PE2 PEM}) 

For each combination of CTRL VARS do 

{ 



} 

Sort PCPsched and PCPjdelay and Gsub in decreasing order of PCP delay [I] . 
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Generate the Branch and bound schedule for Gsub[0], the sub-graph with the worst 
PCPjdelay. Let the schedule be BBjsched[I=0] and the delay be BB_delay[I=0]. 
Initialize worst bb delay = BB delay [ 0] 
For all the other sub-graphs do 



Generate the branching tree with the help of the G(V,E). In this branching tree, the edge 
represents the choices (K and K') and the node represents the variable (K) 
Initialize the current path to the one leading from the top to the leaf in such a way that the 
DFG corresponding to this path gives the worst _bb delay. The path is nothing but a list 
of edges tracing from the top node till the leaf 

Processes with large execution times have a greater impact on the schedule than the 
shorter processes. Hence, large processes are scheduled in a special way. The shorter 
processes can be scheduled using the PCP scheduling algorithm. Since PCP scheduling is 
done for most of the processes, the complexity stays closer to 0(N), where N is the number 
of processes to be scheduled. 

a) Identify the first set of processes that need to be scheduled onto the same processor 
which are computationally complex. Let's call them MP1, MP2.... (Macro process 1 
etc.) 

b) Schedule all the processes till these macro processes in the data flow graph using PCP 
scheduling. 

c) Calculate the estimated execution time of the smaller processes to find the start time 
of each of the macro process. 

d) Determine the next set of such macro processes in the DFG. Let's call them MP subl, 
MP_sub2... 

e) For processes amidst these two sets of macro processes, PCP scheduling is used. 



{ 



if(PCPjdelay[I] < worst _bb_delay) then 
BBjsched[I] = PCP_sched[I] ; 
BB_delay[I] = PCP_delay[I] ; 



else 



Generate BB__sched[I] and BBjdelay[I]; 
If(BB_delay[I] > worst_bb_delay[I]) then 
Worst _bbjdelay = BBjdelay[I]; 
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f) For processes occurring after the second set of macro processes, the execution times 
are added up to get the total execution time. 

g) Now, determine the order of execution of these processes by estimating the worst- 
case execution time in each case and selecting the best amongst them. 

h) After this scheduling, the block after the second set of macro processes is taken as the 
current DFG and steps a-g re implemented. 

i) Step h is repeated till the end of DFG is reached. 
Schedule merging : 

In the schedule table there are some columns representing paths that are complete and 
some that are not. The incomplete paths can be now referred to as parent paths of possible 
complete paths. 

In the example shown in Fig. 19, for earliest evaluation of all conditional variables 
(viz. D, C, K) it is necessary to evaluate D first, then C and then K. Therefore the tree of 
possible paths is as shown in Fig. 28. Now, while creating the schedule table, initially only 
considered are the full possible paths i.e. , the 6 paths listed in Fig. 28. Scheduling is 
performed by the suggested algorithm. This will fill these columns. Then the remaining 
column of partial paths (i.e., D, D C, ...etc) is created. These are now just empty columns. 
Now if a process has the same start times in multiple columns, it is pushed into the parent 
empty column. 

For example, from the Fig. 4 of Pop's paper "scheduling of conditional process graphs 
for the synthesis of embedded systems" one sees that processes PI, P2, P6, P9, P10, PI 1, Pe 
and so on have the same time of occurrences in both paths. Therefore one can push them into 
the parent column, of DC because it means that these processes can be scheduled for 
execution (not necessarily executed) by the logic schedule manager after C has been 
evaluated. 

This approach tries to obtain the worst case delay and merge all paths to that timeline. 
Since the DCK path had the worst case optimal delay, all other full paths were adjusted to 
match this path. But it is also necessary to consider the probability of the occurrence of all the 
full paths (6 of them). Then preferably the bottom 10% of the paths are pruned out. That is, 
one disregards those full paths whose probability of occurrence is less than a threshold value 
when compared to the path with most probable occurrence. 

Then a path is selected from the remaining ones, whose probability of occurrence is 
the highest. This will be the new reference to which all the remaining paths will adjust. Now 
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it is likely that these chosen full paths and the disregarded full paths, share certain partial 
paths (parent paths). Therefore, while allocating the start times for the processes that fall 
under these shared partial paths, one must allocate them based on the worst (most delay 
consuming) disregarded path which needs (shares) these processes. While performing 
5 schedule merging, all data dependencies must be respected. 

Example: Modified PCP for the DFGfl] corresponding to the branching tree path 
DCK' 

This example shows how the modified PCP approach of this invention out-performs 
the conventional PCP algorithm. Decision taken at each schedule step has been illustrated. 
1 0 Current time = 1 
Ready List: 1, 11 

Schedule 1^PE2 (next schedule time = 4) 1 1->PE3 (Next schedule time = 8) 
Currenttime = 4 
Ready list: 2,3 
1 5 There is a conflict; 

one needs to determine the next possible conflict between the remaining tasks dependent on 
2,3. 

Possible conflicts on the conflict table: 

Processing 

Node_index List of possible conflicts Element 

7 [9] 1 

9 [7] 1 

10 [] 1 

5 [17] 2 

17 [5] 2 



6 [) 3 

8 [] 3 



Case 1: 7,9 
20 Case 2: 5,17 



Table 4, Conflict Table 



ASAP and ALAP times are used to determine the amount of conflict for each case. For this 

example, Case 1 has more conflict. Hence, consider case 1 . 

Now, possible orders of execution: [2,3,7,9], [2,3,9,7],[3,2,7,9],[3,2,9,7]. 
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Determine the worst-case execution time for each of these paths and select the order with 
minimum worst-case execution time. 
Worst-case execution times: 
[2,3,7,9] 34 
5 [2,3,9,7] ^ 36 
[3,2,7,9] -» 38 
[3,2,9,7] -> 32 

Hence, the best execution order is [3,2,9,7]. 
Schedule 3->PEl (next schedule time = 8) 
1 0 Current time = 8 (min(next schedule times not yet used as current time)) 
Ready list: 12,2,14,6 

Schedule 14^PEx (nst = 10) 2 -> PE1 (nst = 13) 
There now is a conflict between 6 and 12. 

There are no conflicts between the remaining tasks dependent on 6,12. Therefore the only 
15 possible orders of execution are: 6,12 and 12,6 
Worst-case execution times: 
[6,12] 22 
[12,6] -» 25 

Therefore, [6,12] is a better choice. 
20 Schedule 6->PE3 (nst = 16) 
Current time = 1 3 
Ready list: 5 

Schedule 5-»PE2 (nst = 23) 
Current time = 1 6 
25 Ready list: 12, 8, 9 

Schedule 9 -» PE1 (nst = 22) 

There is now a conflict between 8 and 12. 

There are no conflicts between the remaining tasks dependent on 8,12. Therefore the only 

possible orders of execution are: 8,12 and 12,8 

30 Worst-case execution times: 

[8,12] 18 
[12,8] -> 15 

Therefore, [12,8] is a better choice. 
Schedule 12^PE3 (nst = 22) 
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Current time = 22 
Ready list: 16,8 

There is now a conflict between 8 and 16. 

There are no conflicts between the remaining tasks dependent on 8,16. Therefore the only 
5 possible orders of execution are: 8,16 and 16,8 
Worst-case execution times: 
[8,16] -» 10 
[16,8] 13 

Therefore, [8.16] is a better choice. 
10 Schedule 8-»PE3 (nst = 26) 
Current time = 23 
Ready list: 15,7 

Schedule 15 -» PE2 (nst = 28) 7 ^ PE1 (nst = 31) 
Current time = 26 
15 Ready list: 16 

Schedule 16 -» PE3 (nst = 30) 
Current time = 30 
Ready list: 17 

Schedule 17 -» PE2 (nst = 32) 
20 Current time = 31 
Ready list: 10 

Schedule 10 -> PEL (nst = 36) 

Schedule table entry for DFG[1] for our method and PCP method. 
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Table 5, Schedule Table for DFG (1) 

Similarly, Schedule table entries can be generated for the remaining DFGs 



Our PCP 



Process 


DC K 


DCK 


DCK 


DCK 


DCK 


DC 


DC 


1 


1 


1 


1 


1 


1 


1 


1 


2 


8 


4 


8 


4 


4 


8 


4 


3 


4 


9 


4 


9 


9 


4 


9 


4 








9 


9 




9 


5 


13 


9 


13 






13 




6 


8 


14 


8 


13 


13 


8 


13 


7 


23 


19 


23 


14 


14 


23 


21 


8 


22 


22 


22 


21 


21 


16 


21 


9 


16 


27 


16 


22 


22 


16 


29 


10 


31 


33 


31 


28 


28 


31 


35 


11 


1 


1 


1 


1 


1 


1 


1 


12 


16 


8 


16 


8 


8 






13 












13 


13 


14 


8 


25 


22 


13 


13 


8 


13 


15 


23 


19 






19 






16 


26 


26 


26 


25 


25 






17 


30 


30 


30 


29 


29 


21 


21 


Exec. T 


35 


37 


35 


32 


32 


35 


39 



5 Table 6, Schedule Table for Remaining DFGs 
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Branch and Bound scheduling 

Arranging the DFG in the decreasing order of their MPCP_delay (Exec T in the 
tables), one gets 

DFG[0] ^ DC MPCP_delay[0] = 39 
5 DFG[1] ->DCK MPCP_delay[l] = 35 

DFG [2] DC K MPCP_delay[2] = 35 

DFG [3] -> DC MPCP_delay[3] = 35 

DFG [4] -> DC K MPCP_delay[4] = 32 

DFG[5] -> DCK MPCP_delay[5] = 32 
10 Now, one needs to determine the Branch and Bound Schedule for DFG[0]. Branch and 

Bound gives the optimal schedule. Here, the schedule produced by the modified PCP 

approach of the invention was the optimal schedule in this case. Hence, branch and bound 

also produces the same schedule. Since, the remaining delays are all lesser than the branch 

and bound delay produced, there is no need to do branch and bound scheduling for the 
1 5 remaining DFGs. 

Schedule Merging: 

Schedule merging gives the optimal schedule for the entire CDFG. Optimal schedule 
should take care of the fact that the common processes have the same schedule. If the 
common processes have different schedules, one modifies the schedule with lesser delay. 
20 Schedule merging for (DCK, DC K ) to give the optimal schedule for DC is done here. 
Processes common: 1,2,3,5,6,7,8,9,10,1 1,12,14,16,17 

From the schedule table, it can be observed that only 14 has a different schedule time. To 
make it equal, we push 14 down the schedule. The modified table is shown below. 
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Table 7, Modified Schedule Table for D C K and DC K 
Schedule merging for D C K and D C K to obtain optimal schedule for D C 
Processes common: 1 ,2,3,4,6,7,8,9, 1 0, 1 1 , 1 2, 1 4, 1 6, 1 7 
5 Here, all the processes have the same schedule. Hence, there is no need to do schedule 
merging. 

Schedule merging for DC and D C to obtain optimal schedule for D 
Processes common: 1 ,2,3,6,7,8,9, 1 0, 1 1 , 1 2, 1 4, 1 6, 1 7 
Here, 2,3,6,8,9,10,14,16 have different schedules. 
10 Hence, one needs to modify the schedules of DC K as it has a lesser delay 
E.g. Interchange schedules of 2 and 3. 
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Table 8, Modified Schedule Table for DC and DC . 
Schedule merging for D C and DC to obtain optimal schedule for D 
Processes common: 1,2,3,6,7,8,9,10,1 1,13,14,17 
5 Here, 2,3,6,7,8,9,10,14 have different schedules. 

Hence, one needs to modify the schedules of D C as it has a lesser delay. 
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Table 9, Modified Schedule Table for D C and D C 

Schedule merging for D and D' to obtain optimal schedule for 'true' condition 
Processes common: 1 ,2,3,6,7,8,9, 1 0, 1 1 , 1 4, 1 7 
5 Here, 2,3,6,7,8,9,10,14,17 have different schedules. 

Hence, one needs to modify the schedules of D as it has a lesser delay. 
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Table 10, Modified Schedule Table for D and D 

Here, schedule for D also needed to be modified without changing the total delay. 
Sometimes, the delay could be worsened due to schedule merging. 
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Table 11, Final Schedule Table. 
5 Reconfiguration 

Reconfiguration times have not been taken into account in the scheduling of CDFGs. 
An example shows how this time can influence the tightness of a schedule. Consider the 
following task graph (Fig. 29 ). X, V and Z are processes performed by the same processing 
element. 

10 In the task graph, say 'a' is a variable that influences the decision on which of the two 

mutually exclusive paths (dash-dotted or dotted) will be taken, and a is known during run 
time but much earlier than 4 m 5 and c z' have started. Let x, v, z and X be the times taken by 
processes in the event that 'a' happens to force the dash-dotted path to be taken. Let 6, 5, r| 
be the reconfiguration times for swapping between the processes on the unit. Given these 

1 5 circumstances, if run time scheduling according to [68] is applied, it neglects the 

reconfiguration times and provides a schedule of five cycles as shown on the left hand side. 
But if reconfiguration time were to have been considered, a schedule more like the one on the 
right hand side is tighter with 4 clock cycles. This example shows the importance of 
considering reconfiguration time in a reconfigurable processor, if fast swaps of tasks on the 

20 processing units need to be performed. 
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Therefore incorporating Reconfiguration time into Control flow graphs involves the 
following steps: 

i. Special edges are added onto the control flow graphs between a similar set of 
processes, which will be executed on the same processor with or without 

5 reconfiguration. In other words, these additional edges are inserted and the 

modified PCT scheduling as above is carried out with these in place. 

ii. Reconfiguration times affect the worst-case execution time of loopy codes. So this 
has to be taken care of, when loopy codes are being scheduled. 

iii. Care needs to be taken to schedule the transfer of reconfiguration bit-stream from 
10 the main memory to the processor memory. 

Loop-based scheduling 

In static scheduling, loops whose iteration counts are not known at compile time 
impose scheduling problems on tasks which are data dependent on them, and those tasks that 
have resource dependency on their processing unit. Therefore, this preferred, exemplary 
1 5 embodiment takes into account cases which are likely to impact the scheduling to the largest 
extent and provided solutions. 

Case 1: Solitary loops with unknown execution time. Here, the problem is the execution 
time of the process is known only after it has finished executing in the processor. So static 
scheduling is not possible. 
20 Solution: (Assumption) Once a unit generates an output, this data is stored at the consuming 
/ target unit's input buffer. Referring to the scheduled chart of Fig. 30, each row represents 
processes scheduled on a unique type of unit (Processing Element). Let PI be the loopy 
process. 

From Fig. 30 we see that 
25 P3 depends on PI and P4, 

P2 depends on PI, 

P6 depends on P2 and P5. 

If PI J s lifetime exceeds the assumed lifetime (most probable lifetime or a unit 
iteration), then all dependents of PI and their dependents (both resource and data) should be 
30 notified and the respective Network Schedule Manager (NSM) and Logic Schedule Manager 
(LSM), of Fig. 32, should be delayed. Of course, this implies that while preparing the 
schedule tables, 2 assumptions are made. 
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1) The lifetimes of solitary loops with unknown execution times are taken as per 
the most probable case obtained from prior trace file statistics (if available and 
applicable). Otherwise unitary iteration is considered. 

2) All processes that are dependent on such solitary loop processes are scheduled 
with a small buffer at their start times. This is to provide time for notification 
through communication channels about any deviation from assumption 1 at 
run time. 

If assumption 1 goes wrong, the penalty paid is: 

Consider the example in Fig. 26 where two processes in the ready list are being 
scheduled based on PCP. Now by PCP method if X A > X B and PI and P2 do not share the 
same resource, then PA is scheduled earlier than PB. It has been assumed that X A is due to 
most probable execution time of Loop PI . But at runtime if Loop PI executes a lesser 
number of times than predicted and therefore resulting in A, A being < ^b, then the schedule of 
PA earlier than PB results in a mistake. 

The time difference between both possible schedules is calculated. It is not, at this 
point, proposed to repair the schedule because all processes before PI have already been 
executed. And trying to fit another schedule at run time, requires intelligence on the 
communication network which is a burden. But on the brighter side, if at run time Loop PI 
executes a greater number of times than predicted, then X A will still be > A, B - Therefore the 
assumed schedule holds true. 

Case 2: A combination of two loops with one loop feeding data to the other in an iterative 
manner. 

Solution: Consider a processing element, PA, feeding data to a processing element, PB, in 
such a manner. For doing static scheduling, if one loop unrolls them and treats it in a manner 
of smaller individual processes, then it is not possible to assume an unpredictable number of 
iterations. Therefore if an unpredictable number of iterations is assumed in both loops, then 
the memory foot-print could become a serious issue. But an exception can be made. If both 
loops at all times run for the same number of iterations, then the schedule table must initially 
assume either the most probable number of iterations or one iteration each and schedule 
PA,PB,PA,PB and so on in a particular column. In case the prediction is exceeded or fallen 
short of, then the NSM and LSMs must do 2 tasks: 

1) If the iterations exceed expectations, then all further dependent processes 
(data and resource) must be notified for postponement and notified for 
scheduling upon the iterations completion with an appropriate difference in 
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expected and obtained at run time, schedule times. If the iterations fall short of 
expectations, then all further schedules must only be preponed (moved up). 



2) Since the processes PA and PB should denote single iteration in the table, 



5 



their entries should be continuously incremented at run time by the NSM and 
the LSMs. The increment for one process of course happens for a 



predetermined number of times, triggered off by the schedule or execution of 
the other process. For example in Fig. 31, we see that PA = 10 cycles, PB = 20 
cycles and hence if both loops run for five times, then the entry in the column 



increments as shown. 



10 Only in such a situation can there be preparedness for unpredictable loop iteration counts. 
Case 3: A loop in the macro level i.e. containing more than a single process. 
Solution: In this case, there are some control nodes inside a loop. Hence the execution time 
of the loop changes with each iteration. This is a much more complicated case than the 
previous options. Here lets consider a situation where there is a loop covering two mutually 

1 5 exclusive paths, each path consisting of two processes (A,B and C,D) with (3,7 and 15,5) 

cycle times. In the schedule table there will be a column to indicate an entry into the loop and 
two columns to indicate the paths inside the loop. Optimal scheduling inside the loop can be 
achieved, but in the global scheme of scheduling, the solution is non-optimal. However this 
cannot be helped because to obtain a globally optimal solution, all possible paths have to be 

20 unrolled and statically scheduled. This results in a table explosion and is not feasible in 
situations where infinite number of entries in table are not possible. Hence, from a global 
viewpoint the loop and all its entries are considered as one entity with the most probable 
number of iterations considered and the most expensive path in each iteration is assumed to 
be taken. For example in the above case, path C,D is assumed to be taken all the time. 

25 Now, a schedule is prepared for each path and hence entered into the table under two 

columns. When one schedule is being implemented, the entries for both columns in the next 
loop iteration is predicted by adding the completion time of the current path to both column 
entries (of course while doing this care should be taken not to overwrite the entries of the 
current path while they are still being used). Then when the current iteration is completed and 

30 a fresh one is started, the path is realized and the appropriate (updated / predicted) table 
column is chosen to be loaded from the NSM to the LSMs. 
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Network architecture 

In order to coordinate the mapping of portions of the schedule table onto 
corresponding CLUs, we propose the following architecture. The reconfigurable unit 
interfaces with a host processor and other I/O and memory modules. 

The Network Schedule Manager (Fig. 32) has access to a set of tables, one for each 
processor. A table consists of possible tentative schedules for processes or tasks that must be 
mapped onto the corresponding processor subject to evaluation of certain conditional control 
variables. The Logic Schedule Manager schedules and loads the configurations for the 
processes that need to be scheduled on the corresponding processor, i.e., all processes that 
come in the same column (a particular condition) in the schedule table. In PCP scheduling, 
since the scheduling of the processes in the ready list depends only on the part of the paths 
following those processes, the execution time of the processes shall initially conveniently 
include the configuration time. 

Once a particular process is scheduled and hence removed from the ready list, another 
process is chosen to be scheduled based on the PCP criteria again. But this time the execution 
time of that process is changed or rather reduced by using the reconfiguration time, instead of 
the configuration time. Essentially, for the first process that is scheduled in a column, 

the completion time = execution time + configuration time. 

For the next or successive processes, 
completion time = predecessor 's completion time + execution time + reconfiguration time. 

Assuming that once a configuration has been loaded into the CM, the process of 
putting in place the configuration is instantaneous, it is always advantageous to load 
successive configurations into the CM ahead of time. This will mean a useful latency hiding 
for loading a successive configuration. 

The reconfiguration time is dependent on two factors: 



The Network Schedule Manager should accept control parameters from all LSMs. It 
should have a set of address decoders, because to send the configuration bits to the Network 
fabric consisting of a variety of switch boxes, it needs to identify their location. Therefore for 
every column in the table, the NSM needs to know the route apriori. One must not try to find 
a shortest path at run time. For a given set of processors communicating, there should be a 
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1) 



How much configuration data needs to be loaded into the CM (Application 
dependent) 

How many wires are there to carry this info from the LSM to the CM 
(Architecture dependent) 



2) 
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fixed route. If this is not done, then the communication time of the edges n the CDFG cannot 
be used as constants while scheduling the graph. 
For any edge the, 

communication time = a constant and uniform configuration time + data transaction time. 

The Network architecture consists of switch boxes and interconnection wires. The 
architecture will be based on the architecture described in [1]. This will be modeled as a 
combination of "Behavioral" and "Structural" style VHDL. Modifications that will be made 

are: 

a. The Processing Elements derived in section 3 will be used instead of the four 
input LUTs that were used in Andre's model. 

b. RAM style address access will be used to select a module or a switch box on the 
circuit. 

c. Switch connections that are determined to be fixed for an application will be 
configured only once (at the start of that application). 

d. Switch connections that are determined to be fixed for all applications will be 
shorted and the RC model for power consumption for that particular connection 
will be ignored for power consumption calculations. 

e. The number of hierarchy levels will be determined by the application that has the 
maximum number of modules, because there is a fixed number of modules that 
can be connected 

There will be one Network Schedule Manager (NSM) modeled in "Behavioral" and 
"Structural" style VHDL. It will store the static schedule table for the currently running 
application. The NSM collects the evaluated Boolean values of all conditional variables from 
every module. 

For placing modules on the network two simple criteria are used. These are based on 
the assumption that the network consists of Groups of four Processing Unit Slots (G4PUS) 
connected in a hierarchical manner. 

Note: A loop could include 0 or more number of CGPEs. 

Therefore the following priority will be used for mapping modules onto the G4Pus: 
a. A collection of one to four modules which are encompassed inside a loop shall be 
mapped to a G4PUS. 

i. If there are more than four modules inside a loop, then the next batch 
of four modules are mapped to the next (neighboring) G4PUS. 
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ii. If the number of CGPEs in a loop > 2, then they will have greater 
priority over any FGPEs in that loop for a slot in the G4PUS. 

b. For all other modules: 

iii. CGPE Modules with more than one Fan-in from other CGPEs will be 
5 mapped into a G4PUS. 

iv. CGPE Modules with more than one Fan-in from other FGPEs will be 
mapped into a G4PUS. 

Note: The priorities are based on the importance for amount of communication 
between modules. Both Fan-ins and Fan-outs can be considered, for simplicity, Fan-ins to 
10 CGPEs are considered here only. 
Testing Methodology 

In this research effort, one focuses mainly on reducing the number of reconfigurations 
that need to be made for running an application and then running other applications on the 
same processor. One also aims to reduce the time required to load these configurations from 
1 5 memory in terms of the number of configuration bits corresponding to the number of 
switches. 

Time to execute an application for a given area (area estimate models of XILINX 
FPGAs and Hierarchical architectures can be used for only the routing portion of the circuit.) 
and a given clock frequency can be measured by simulation in VHDL. 

20 The time taken to swap clusters within an application and swap applications 

(reconfigure the circuit from implementing one application to another) is dependent on the 
similarity between the successor and predecessor circuits. The time to make a swap will be 
measured in terms of number of bits required for loading a new configuration. Since a RAM 
style loading of configuration bits will be used, it is proven [2] to be faster than serial loading 

25 (used in Xilinx FPGAs), Speed above the RAM style is expected for two reasons: 

a) The address decoder can only access one switch box at a time. So the greater the 
granularity of the modules, the fewer the number of switches used and hence configured. 

b) Compared to peer architectures which have only LUTs or a mixture of LUTs and 
CPGEs with low granularity (MAC units), CGPEs are expected to be of moderate granularity 

30 for abstract control-data flow structures in addition to FGPEs. Since these CPGEs are derived 
from the target applications, their granularity to be the best possible choice for a 
reconfigurable purpose is expected. They are modeled in "Behavioral" VHDL and are 
targeted to be implemented as ASICs. This inherently would lead to a reduced amount of 
configurations. 
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The time taken to execute each application individually will be compared to available 
estimates obtained for matching area and clock specifications from work carried out by other 
researchers. This will be in terms of number of configurations per application, number of bits 
per configuration, number of configurations for a given set of applications and hence time in 
seconds for loading a set of configurations. 

Regarding power consumption, sources of Power consumption for a given application 
can be classified into four parts: 

a. Network power consumption due to configurations with an application. This is 
due to the Effective Load Capacitance on a wire for a given data transfer from one module to 
another for a particular configuration of switches. 

Note: The more closed switches a signal has to pass through, the more the 
effective load capacitance and resistance. Shorted switches are not considered to contribute to 
this power. 

b. Data transfer into and out of the Processor 

Note: This can have a significant impact on the total power in media rich or 
communication dominated applications ported onto any processing platform. 

c. Processing of data inside a module. 

Note: This will require synthesizable VHDL modules. But since the focus 
here is on reducing power due to reconfiguration, this is presently left for future work. 

d. The Clock distribution of the processor. 

Note: This can be measured if the all parts of the circuit are synthesizable. But 
the focus here is on a modeling aspect and this measurement is not presently considered. 

At the level of modeling a circuit in VHDL, it is possible to only approximately 
determine the power consumptions. One can use the RC models of XILINX FPGAs and [1] 
architectures to get approximate power estimates. Power aware scheduling and routing 
architecture design are complex areas of research in themselves and are not the focus here. 
Here the focus is on reducing the amount of reconfigurations, which directly impacts the 
speed of the processor and indirectly impacts the power consumption to a certain extent. 
Overall Architecture 

Tool Set: Profiling, Partitioning, Placement and Routing 

One aspect of the present invention aids the design, the circuitry or architecture of a 
dynamically reconfigurable processor through the use of a set of analysis and design tools. 
These will help hardware and system designers arrive at optimal hardware software co- 
designs for applications of a given class, moderately complex programmed applications such 
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as multimedia applications. The reconfigurable computing devices thus designed are able to 
adapt the underlying hardware dynamically in response to changes in the input data or 
processing environment. The methodology for designing a reconfigurable media processor 
involves hardware-software co-design based on a set of three analysis and design 
5 tools[AK02]. The first tool handles cluster recognition, extraction and a probabilistic model 
for ranking the clusters. The second tool, provides placement rules and feasible routing 
architecture. The third tool provides rules for data path, control units and memory design 
based on the clusters and their interaction. With the use of all three tools, it becomes possible 
to design media(or other) processors that can dynamically adapt at both the hardware and 

10 software levels in embedded applications. The input to the first tool is a compiled version of 
the application source code. Regions of the data flow graph obtained from the source code, 
which are devoid of branch conditions, are identified as zones.Clusters are identified in the 
zones, by representing candidate instructions as data points in a multidimensional vector 
space. Properties of an instruction, such as location in a sequence, number of memory 

1 5 accesses, floating or fixed-point computation etc., constitute the various dimensions. As 

shown in Fig. 33, clusters obtained from the previous tool, tool set 1, are placed and routed 
by tool set 2, according to spatial and temporal constraints (Fig. 34). The processor (of the 
compiler) can be any general purpose embedded computing core such as an ARM core or a 
MIPS processor These are RISC cores and hence are similar to general purpose machines 

20 such as UltraSPARC. The output of the tool is a library of clusters and their interaction. (A 
cluster comprises of sequential but not necessarily contiguous assembly level instructions). 
The clusters represent those groups or patterns of instructions that occur frequently and hence 
qualify for hardware implementation. To maximize the use of reconfigurability amongst 
clusters, possible parallelism and speculative execution possibilities must be exploited. 

25 Referring to Fig. 33, the methodology for designing a reconfigurable media processor 

involves hardware-software co-design based on the set of three analysis and design tools [ 
83,84]. The first tool, tool set 1, is the profiling and partitioning step that handles cluster 
recognition, extraction and a probabilistic model for ranking the clusters. The second tool, 
tool set 2, provides placement rules and a feasible routing architecture. The third tool, tool set 

30 3, provides rules for task scheduling, data path, control units and memory design based on the 
clusters and their interaction. Tool set 3 generates all possible execution paths and 
corresponding scheduling tables for each. Following that it maps the tasks into the 
reconfigurable area. As a modification, the proposed approach, instead of using compiled 
version of, for example, the MPEG4 decoder source code, intermediate three-address code is 
11 561 58 v2 71 




An, 



u; Docket No, 913S-0I4S 



10 



15 



20 



25 



generated from the high level C code. Machine independence and control flow information 
are still kept as is with this approach. Partitioning tool analyzes the intermediate code and 
extracts the control-data flow graph (CDFG). Each bulk of pure data dependent code in 
between the control structures is defined as a zone. Then the partitioning tool runs a longest 
common subsequence type of algorithm to find the recurring patterns between potential zones 
to run on hardware. Building blocks represent those groups or patterns of instructions that 
occur frequently and hence qualify for hardware implementation. By pattern one means a 
building block that consists of a control flow structure. A pattern may also include a group of 
building blocks that are only data dependent. Control structure may be a combination of if- 
else and loop statements with nested cases. Output of the partitioning tool is a library of 
building blocks and their interaction. Interaction information includes how many times two 
building blocks exchange data and size of the data exchanged. The tool also provides number 
of clock cycles required to execute each building block. In addition, input output pins and 
area information for each building block are provided. With this information an 
interconnection pattern can be determined prior to execution. That helps to exploit the 
locality to thereby simplify the interconnection structure and reduce the usage of global 
buses, fan-ins and fan-outs. The placement tool places the building blocks that are 
exchanging data more frequently close together. Clusters obtained from tool set 1 are placed 
and routed by tool set 2 in Fig. 33, according to spatial and temporal constraints as 
diagrammatically illustrated in Fig. 34. To maximize the use of reconfigurability amongst 
clusters, possible parallelism and speculative execution possibilities are exploited. 
Heterogeneous Hierarchical Architecture 

Aggarwal [85] says that hierarchical FPGAs (H-FPGAs) (Fig. 35) can implement 
circuits with fewer routing switches in total compared to symmetrical FPGAs. According to 
Li [86], for H-FPGAs the amount of routing resources required is greatly reduced while 
maintaining a good routability. It has been proved that the total number of switches in an H- 
FPGA is less than in a conventional FPGA under equivalent routability [87]. Having fewer 
switches to route a net in H-FPGAs reduces the total capacitance of the network. Therefore it 
can implement much faster logic with much less routing resources compared to standard 
FPGA. H-FPGAs also offer advantages of more predictable routing with lower delays. Hence 
the density of H-FPGAs can be higher than conventional FPGAs. In the case of the present 
invention, compared to hierarchical and symmetrical FPGA approaches, building blocks are 
of variable size. Classical horizontal, vertical channel will not result in an area efficient 
solution Consistent channel capacity at each hierarchy level will not work because of the 
1t5615Sv2 72 



Art^^Docket No. 9 1 38-01 4S 

variable traffic between the building blocks even at the same hierarchy. Due to variable 
traffic among clusters and non-symmetric characteristics, different types of switches are 
needed at each hierarchy level. All these factors result in heterogeneity between groups of 
building blocks at the same hierarchy level as opposed to classical H-FPGA approach. 
5 Therefore a heterogeneous hierarchical routing architecture that makes use of the 

communication characteristics is essential to implement power and time efficient solution. 
Proposed Architecture 

The network scheduler, building blocks, switches and wires form the reconfigurable 
unit of present invention. A profiling and partitioning tool lists building blocks such as 
10 B={Bi, B 2 , Bk} where BjeB. Based on data dependency between the building blocks, disjoint 
subsets of B are grouped together to form clusters. A building block should appear only in 
one cluster. 

In Fig. 36 A, at time t=tj , Bi receives (a,b) and (c,d) from memory. If multiple copies 
of Bj are available, then without a resource conflict both will run at the same time. However 

1 5 that would work against the definition of a reconfigurable solution. In second scenario (Fig. 
36 B), Bi processes data of the most critical path first, (B3 B2 or B5 B4) while the second 
path is waiting. For such resource or scheduling conflicts we introduce network scheduler 
module, which is a controller unit over the reconfigurable area. Handling dynamic 
reconfiguration and context switching are the major tasks of this unit. Most critical path is 

20 initially loaded into network scheduler. At run time, if a path that is not on the critical path 
needs to be executed, it is the network scheduler's job to do context switching and loading 
the schedule for that new path. The network scheduler offers control mechanism over data 
transmission between building blocks as well. Buffering is needed when receiver needs to 
process bulks of data at a time. For a given context if consumer demands data in a block 

25 manner then the receiver should rearrange the incoming data format. Both sender and 
receiver should be context aware. Buffers are only kept at the receiver side. A producer 
simply dumps the data to the bus as soon as it is available. The receiver should be aware of 
the context of each request and make a decision based on the priority in order to prevent 
collision. If the receiver needs to get data from more than one sender, then those senders, 

30 which are in the ok list, are allowed to transmit data whereas other requests should be denied. 
This is again handled by the collusion prevention mechanism. The connection service 
mechanism brings a control overhead cost however it provides controlled router service, 
efficient resource usage and parallelism. 
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As shown in Fig. 37, clusters of building blocks form level-1 (M) modules. Similarly 
clusters of M modules form level-2 (C) modules. One defines two types of switches: local 
(LS) and gateway switches (GS). Local switches function within level-1 and level-2 modules. 
Gateway switches allow moving from one hierarchy level to another. Depending on the place 
of LS or GS, there may be multiple LSs needed for LS to LS connections. Connection 
between the building blocks of the same level-2 module is handled through only local 
switches. For all other connections gateway switches distribute the traffic as shown in Fig. 
38. Building block uses local global bus to connect to gateway switch of the module that 
building block belongs to. Bus capacity and gateway switch complexity increase as the 
hierarchy increases and switches are variable in flexibility even at the same hierarchy level. 

Level-1 blocks use local global bus to connect to the gateway switch of the cluster 
that the building block belongs to. If a block in module 2 of cluster 1 sends data to a block in 
module 1 of cluster 2, data goes through the global buses only following Source Block, GS in 
CI , GS in LeveB, GS in C2 and finally reaching the Destination Block Fig. 38. Dashed lines 
represent the local connection through local switches. 
Methodology 

As indicated in Fig. 39, the methodology in accordance with this invention, involves 
implementation of packing, hierarchy formation, placement, network scheduling and routing 
tools. New cost function metrics are generated for the routability driven packing algorithm. 
The cost function takes into account each possible execution path of the application obtained 
from a given CDFG, library of variable size building blocks, building block timing and 
dependency analysis. The cost function will simplify the complexity of the placement and 
routing steps since constraints of these steps are evaluated as early as at the packing step. 
Packing 

Several time or area driven packing with bottom-up or top-down approaches have 
been proposed. As shown in Fig. 39, the present methodology is a bottom-up approach. In 
Lookup Table (LUT) based, or building block based reconfigurable solutions, increasing the 
complexity of the processing element increases functionality and hence decreases the total 
number of logic blocks used by the application and the number of logic blocks on the critical 
path. For a fine-grained approach, more logic blocks will be required to implement the 
circuit. The routing area then may become excessive. In coarse-grained logic, much of the 
logic functionality may be unused wasting area. There is a tradeoff between the complexity 
of logic blocks and area efficiency. A cost function is needed to make the decision of 
inserting a building into one of the candidate clusters. [93] uses a sequential packing 
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algorithm with a cost function depending on the number of intersecting nets between a 
candidate cluster and building block. As a modification to this approach [94] uses time driven 
packing that has the objective of minimizing the connection between the clusters on critical 
path. Building blocks are packed sequentially along the critical path. [95] and [96] are 
5 routability driven packing approaches that incorporate routability metric such as density of 
high fan out nets, traffic in and out of the logic block , number of nets and connectivity into 
packing cost function. All of these approaches are based on fixed K input LUT and N number 
of LUTs in a cluster. In addition to having variable size building blocks, the present approach 
takes into account the control data flow graph of each possible execution path to be handled 

1 0 by the reconfigurable unit. 

For an if-else statement, at compile time one doesn't know if or the else part of the 
statement will be executed. Similarly one may not know how many times a loop will execute. 
Packing of building blocks should be in favor of all possible execution paths. Given that 
configuration is based on the //part of a control statement, when else part of the path is to be 

1 5 executed, the network scheduler should do least amount of reconfigurations. Fig. 40 A shows 
a simple if-else statement with building blocks inside the control structure. As shown in Fig. 
40 B, since two paths can't execute at the same time, a clustering tool groups the building 
blocks that are within the same statement (if or else). If a building block that is appearing in 
the else part happens to occur on the path of Path l then the network scheduler handles the 

20 connection between the two clusters through global switches. Since the architecture needs to 
reconfigure at run time, the present approach prioritizes time over the area constraint. 
Possible waste of area during clustering because of irregular building block or irregular 
cluster shapes at higher hierarchy level is ignored as long as the time constraint is satisfied. In 
addition to the metrics defined in [91, 92], the present invention incorporates the scheduling 

25 information into its cost function. Cost of adding a building block into a cluster depends on 
how timing of the circuit is affected at different possible execution paths. At the packing step 
the tasks of placement and routing are simplified. A set of building blocks, a CDFG for each 
possible execution scenario, the input, output pins of each building block, the number of 
cycles required by each building block, the scheduling information for all possible execution 

30 scenarios are used by the packing tool. The inventors have encountered no work that has been 
done on packing variable size building blocks into variable size clusters using CDFG, 
execution path and scheduling analysis information. 

The packing tool groups the building blocks into level- 1 type clusters. Then those 
clusters are grouped together to form level-two and higher levels. At each hierarchy level, 
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existing clusters and their interaction information are used to form higher-level clusters one 
step at a time. As seen in the example, in the hierarchy formation step (Fig. 39), the process 
continues recursively until level-three is reached. 
Placement 

For a level-one cluster, let n be the number of building blocks, Cy be the number of 
occurrences of a direct link between building blocks Bj and Bj; Dy be the amount of data 
traffic in terms of number of bits transferred between the blocks Bj and Bj through direct links 
where 1 < i < n,\ < j < n. Then cost of data exchange between the two library modules Bi and 
B; is defined as: 



Pre-Placement: building blocks are virtually placed on a grid style to specify if a 
block should be placed to north, south, east or west of another block. This is established by 
using the dependency information. Then placement algorithm uses modified simulated 
annealing method by incorporating the orientation information obtained in this step, which 
helps making intelligent placement decisions. The objective of pre-placement is to place the 
pairs of building blocks that have the most costly data exchange closest to each other. As the 
cost of the link decreases the algorithm tolerates to have a Manhattan distance of more than 
one hop between the pairs of building blocks. This phase guarantees area allocation 
improvement because building blocks are placed based on their dependency leading to usage 
of less number of switches or shorter wires to establish a connection between them. Integer 
programming technique is used to make the decision of the orientation of the building blocks 
with respect to each other. Given that there are n numbers of building blocks, in the worst- 
case scenario, if the blocks are placed diagonally on a grid (assuming that each block is unit 
size of one) then the placement is done on an nxn matrix. Let Pi(x,y) denote the (x,y) 
coordinates of the building block Bj and no other building block have the same (x,y) 
coordinates. The objective function is: 



Fig. 41 A shows the cost matrix of given six blocks (A,B,C,D,E,F). Those six nodes 
are treated as points to be placed on a 6x6 matrix. The output of pre-placement is shown in 
Fig. 41 B. 



Cost 0 = C u x D u 




Where 



fi*,y) = \p t W - PM + \p t (y) - PM - Cost,)- 
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Since scheduling, CDFG and timing constraints have already been incorporated in the 
packing algorithm, the placement problem is made simpler. After completing virtual 
placement for each level-one cluster, the same process continues recursively for level-two 
and higher levels of clusters. 
5 Implementation Results: 
Target Device : x2s200e 



Mapper Version : spartan2e ~ SRevision: 1.16$ 



1 Resource 


2 Bits 


1 ) Configuration file size 


1,442,016 


2) Block RAM bits 


57,344 


3) bits used for logic 


1,384,672 ( 1 - 2) 


Bits /Slice 


-588 




Resource 


Bits 


Configuration Storage 




588 bits/slice * 4 gates/bit 


2352 


Behavior 




588 bits/slice * 1 gate/bit 


588 


Total gates /slice 


2940 



The common part of the Affine-Perspective loop / pre-loop: 

10 Total number of slices used = 893 / 1590 slices 

Number of bits = 893/ 1 590 slices x 588 bits/slice 

= 525,084 / 1,419,870 bits of configuration 
Number of gates = 2940 gates/slice * 893 / 1 590 slices 
= 2,625,420/4,674,600 
1 5 Number of equivalent gates (ASIC) as given by Xilinx map report = 23,760 / 32,548 



(Actual gate counts are accepted to be exaggerated by a factor of 5 by Xilinx) 
Therefore a better estimate of the equivalent gate count = 4752 / 6509 
Configuration: 

20 Configuration speed for Xilinx Spartan 2E chip = 400Mb per sec (approx.) 

Time to configure pre-loop bits= 3.549 ms (1,419,870 divided by 400Mb per sec) 

Time to configure loop bits = 1.312 ms (525,084 divided by 400Mb per sec) (A) 

Max. Clock frequency for loop / pre-loop = 58.727 / 52.059 Mhz 

Clock period =1 7.028 / 1 9.2089 ns (B) 

25 Therefore number of clocks saved in using ASIC for the loop = A divided by B 

= 77,000 clock cycles (approx.) 
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Therefore number of clocks saved in using ASIC for the pre-loop = A divide by B 

= 184,000 clock cycles (approx.) 

A Control Data Flow Graph consists of both data flow and control flow portions. In 
compiler terminology, all regions in a code that lie in between branch points are referred to as 
"basic blocks." Those basic blocks which have additional code due to code movement, shall 
be referred to these as zones because. Also under certain conditions, decision making control 
points can be integrated into the basic block regions. These blocks should be explored for any 
type of data level parallelism they have to offer. Therefore for simplicity in the following 
description, basic blocks are referred to as zones. The methodology remains the same when 
modified basic blocks and abstract structures such as nested loops and hammock structures 
etc. are considered as zones. 

High level ANSI C code of the target application is first converted to an assembly 
code (UltraSPARC). Since the programming style is user dependent, the assembly code needs 
to be expanded in terms of all functions calls. To handle the expanded code, a suitable data 
structure that has a low memory footprint is utilized. Assembly instructions that act as 
delimiters to zones must then be identified. The data structure is then modified to lend itself 
to a more convenient form for extracting zone level parallelism. 

The following are the steps involved in extracting zone level parallelism. 
Step-1: Parsing the assembly files 

In this step for each assembly (.s) file a doubly linked list is created where each node 
stores one instruction with operands and each node has pointers to the previous and next 
instructions in the assembly code. Parser ignores all commented out lines, lines without 
instructions except the labels such as 

Main: 

.LL3: 

Each label starting with .LL is replaced with a unique number (unique over all 
functions) 
Step-2: Expansion 

Each assembly file that has been parsed is stored in a separate linked list. In this step 
the expander moves through the nodes of linked list that stores main.s. If a function call is 
detected that function is searched through all linked lists. When it is found, that function from 
the beginning to the end, is copied and inserted into the place where it is called. Then the 
expander continues moving through the nodes from where it stopped. Expansion continues 
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until the end of main.s is reached. Note that if an inserted function is also calling some other 
function expander also expands it until every called function is inserted to the right place. 
In the sample code of Appendix A, mainO function is calling the findsumO function twice 
and findsumO function is calling the findsubO function. Shown in Appendix C is the 
5 expanded code after considering individual assembly codes of Appendix B. 
Step-3: Create Control Flow Linked List 

Once the main.s function has been expanded and stored in a doubly linked list, the 
next step is to create another doubly linked list, the control flow linked list, Fig. 43, that 
stores the control flow information. This will be used to analyze the control flow structure of 
10 the application code, to detect the starting and ending points of functions and control 
structures (loops, if. .else statements, etc.). 

As the expanded linked list is scanned, nodes are checked if they belong to a: 

• Label or 

• Function or 

1 5 • Conditional or 

• unconditional branch 

In which case, a new node is created to be appended to the control flow linked list by setting 
the member pointers as defined below. 

If the current node is a 
20 • function label 

A pointer to the expanded list pointing to the function label node 

A pointer to the expanded list pointing to the beginning of the function (the next node 

of the function label node) 

A pointer to the expanded list pointing to the end of the function 
25 And node type is set to "function". 

• label 

A pointer to the expanded list pointing to the function label node 

A pointer to the expanded list pointing to the beginning of the label (the next node of the label 
node) 

30 And node type is set to "square". 

• unconditional branch (b) 

A pointer to the expanded list pointing to the branch node 

A pointer to the control flow linked list pointing to the node that stores the matching 
target label of the branch instruction. 
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And node type is set to "dot" 

• conditional branch (bne, ble, bge, ...etc) 

A pointer to the expanded list pointing to the branch node 

A pointer to the control flow linked list pointing to the node that stores the matching 
target label of the branch instruction. 
And node type is set to "circle". 

The control flow linked list output for the findsum.s function is shown in Appendix C. 
Step 4: Modification of Control Structure 

The control structure linked list (which essentially represents the control flow graph 
of the candidate algorithm) is then modified as follows. 

• The pointers from unconditional branch nodes (also called "dot" nodes) to the 
next node in the list need to be disconnected and made NULL. Hence for the "dot" 
node: 

node— ►next = NULL 
for the following node: 
node— ►previous = NULL 

{Exception: if the next node of the "dot" node is itself the target node !} 

• The target nodes of the unconditional branches need to be marked as "Possible 
Exit" nodes. These "Exit" classes of nodes are a subset of the regular "Target" or 
"Square" nodes. 

• If unconditional branch node's rank is higher than target node's rank (indicating a 
feed back or loop), disconnect the link and mark as NULL. 

Hence for the "dot" node: 
node— >to_target = NULL 

But before disconnecting, mark target— >next (which should be a circle) as "loop 
node". 

• In a special case, if an unconditional branch and a square share the same node, 
then the target of that unconditional branch is declared as an exit square with a 
loop type (because, instructions following this square, comprise the meat of the 



do-while loop). This exit square, will not have its next— ► pointing to a circle. The 
circle is accessed through the dot node using the previous— > pointer. Then it is 
marked off as type loop. 
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• If a "Possible Exit 55 node has 2 valid input pointers, and rank of both source 
pointers is lesser than the node in consideration, then it is an "Exit 5 ' node and, 
disconnect the link to the corresponding "dot 55 node, and hence also mark that 
"dot 55 node's target pointer to NULL. In other words, if the node— ^previous 
5 pointer of the "square/target 55 node of the "dot 55 node does not point to the "dot 55 

node, then it has 2 valid pointers. 
Hence for the "dot 55 node: 
node— >to_target = NULL 
A sample high level code is given below, following which is the expanded 
10 assembly file. The control flow linked list is as shown in Fig. 43. After modifications to this 
linked list a structure as indicated in Fig. 44 is obtained. The sample high level code: 
#include<stdio.h> 
void mainQ 

{ 

1 5 int i=0j=0,k=0,l=0,m=0,n=0,p=0,r=0; 

for(i=l;i<10;i++) 

{ 

P = p-8; 
P = P* 7; 

20 } 

i = i+ 1; 

if(i==j) 
{ 

n = 9; 

25 if(k>0) 
{ 

p=19; 

} 

else 

30 { 

r = 23; 

} 

n= 17 + 8; 
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> 

else 

{ 

1= 10; 
5 m = n +r; 

} 

k = k-14; 
k = 7 - 8 * p; 
while(i<p) 
10 { 

P = P * 20; 
p = p-7; 
while(k == 8) 

{ 

15 p = p+17; 

i = i * p; 

} 

p=p-23; 

} 

20 m = m +5; 

n = n +4; 

} 

} 

The expanded assembly file, the gcc (version 2.95.2) compiled code for the 
25 UltraSPARC architecture with node labeling is as follows: 
.file M loop_pattern4.c M 
gcc2_compiled.: 

.global .umul 
.section ".text" 
30 .align 4 

.global main 

.type main,#function 

.proc 020 

main: 



1 I56158v2 



Atu^^Dockei No. 91 38-01 4S 



10 



15 



20 



25 



30 



.LL3: 



.LL6: 



.LL5: 



!#PROLOGUE# 0 

save %sp, -144, %sp 
!#PROLOGUE# 1 

st %g0, [%fp-20] 

st %g0, [%fp-24] 

st %g0, [%fp-28] 

st %g0, [%fp-32] 

st %g0, [%fp-36] 

st %g0, [%fp-40] 

st %g0, [%fp-44] 

st %g0, [%fp-48] 

mov 1 , %oO 

st %oO, [%fp-20] 



Id 

cmp 
ble 
nop 
b 

nop 

Id 
add 
st 
Id 

mov 
sll 
sub 
st 

Id 
add 
st 
b 



[%fp-20], %oO 
%oO, 9 
.LL6 

.LL4 



[%fp-44], %oO 
%oO, -8,%ol 
%ol, [%fp-44] 
[%fp-44], %oO 
%oO, %ol 
%ol, 3, %o2 
%o2, %oO, %oO 
%oO, [%fp-44] 

[%fp-20], %oO 
%oO, 1, %ol 
%ol, [%fp-20] 
.LL3 



ground 



square 3 



circle 6 



dot 4 



square 6 



square 5 



dot 3 
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.LL4: 



nop 
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20 
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.LL8: 



.LL9: 



.LL7: 



Id 


[%fp-20], %o0 


square 4 


add 


%o0, l,%ol 




St 


%ol, [%fp-20] 




Id 


[%fp-20], %o0 




Id 


[%fp-24], %ol 




cmp 


%o0, %ol 




bne 


.LL7 


circle 7 


nop 






mov 


9, %o0 




St 


%o0, [%fp-40] 




Id 


[%fp-28], %o0 




cmp 


%o0, 0 




ble 


.LL8 


circle 8 


nop 






mov 


19, %o0 




St 


%o0, [%fp-44] 




u 
D 


T T Q 




nop 






mov 


23, %o0 


square 8 


St 


%o0, [%fp-48] 




mov 


25, %o0 


square 9 


St 


%o0, [%fp-40] 




b 


.LL10 


dot 10 


nop 






mov 


10, %o0 


square 7 


St 


%o0, [%fp-32] 




Id 


[%Qj-40], %o0 




Id 


[%fp-48], %ol 




add 


%o0,%ol,%o0 
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st %o0, [%fp-36] 



.LL10: 



.LL11: 



.LL13: 



Id 

add 

st 

Id 

mov 

sll 

mov 

sub 

st 

Id 
Id 

cmp 
bl 
nop 
b 

nop 
Id 

mov 

sll 

add 

sll 

st 

Id 

add 

st 



.LL14: 



Id 

cmp 

be 

nop 



[%fp-28], %o0 
%o0, -14, %ol 
%ol, [%fp-28] 
[%fp-44], %o0 
%o0, %ol 
%ol, 3,%o0 
7, %ol 

%ol, %o0,%o0 
%o0, [%fp-28] 

[%fp-20], %o0 
[%fp-44], %ol 
%o0, %ol 
.LL13 

.LL12 



[%fp-44], %o0 
%o0, %o2 
%o2, 2, %ol 
%ol,%o0, %ol 
%ol,2,%o0 
%o0, [%fp-44] 
[%fp-44], %o0 
%o0, -7, %ol 
%ol, [%fp-44] 

[%fp-28], %o0 
%o0, 8 
.LL16 



square 10 



square 11 



circle 13 



dot 12 



square 13 



square 14 



circle 16 
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XL16: 



.LL15: 



.LL12: 



.LL2: 



b 

nop 

Id 
add 
st 
Id 
Id 

call 
nop 

st 
b 

nop 

Id 

add 
st 
b 

nop 

Id 
add 
st 
Id 
add 
st 

ret 

restore 



.LL15 



[%fp-44], %o0 
%o0, 17,%ol 
%ol,[%fp-44] 
[%fp-20], %o0 
[%fp-44], %ol 
.umul, 0 

%o0, [%fp-20] 
XL 14 



[%fp-44], %o0 
%o0, -23,%ol 
%ol,[%fp-44] 
XL 11 



[%fp-36], %o0 
%o0, 5, %ol 
%ol, [%fp-36] 
[%fp-40], %o0 
%o0, 4,%ol 
%ol,[%fp-40] 



XLfel: 



dot 15 



square 16 



dot 14 



square 15 



dot 11 



square 12 



square 2 



.size main,.LLfel-main 

.ident "GCC: (GNU) 2.95.2 19991024 (release)" 
Step 5: Creation of Zones 
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Operation on the modified structure of Fig. 44, in Fig. 45, to extract all possibilities of 
parallelism and reconfiguration, zones are identified in the modified structure. But to identify 
such sections, delimiters are needed. A delimiter can be any of the following types of nodes: 

(i) Circle 

(ii) Dot 

(iii) Exit square 

(iv) Square 

(v) Power 

(vi) Ground. 

A 'Circle 5 can indicate the start of a new zone or the end of a zone. A 'Dot' can only 
indicate the end of a zone or a break in a zone. An 'Exit square' can indicate the start of a 
new zone or the end of a zone. A 'Square' can only indicate the continuation of a break in the 
current zone. A 'Power' can only indicate the beginning of the first zone. A 'Ground' can 
only indicate the end of a zone. 

Fig. 45 shows example zones to illustrate the use of delimiters. Three zones, 1, 2, and 
3 all share a common node, 'Circle 6'. This node is the end of Zone 1 and the start of zones 2 
and 3. Zone 1 has the 'Power' node as its start, while Zone 6 has 'Ground' node as its end. 
The 'Dot 3' in Zone 3 indicates the end of that zone while 'Dot 4' indicates a break in Zone 
2. This break is continued by 'Square 4'. In Zone 4, 'Square 9' indicates the end of the zone 
while it marks the start of Zone 5. 

This function identifies zones in the structure, which is analogous to the numbering 
system in the chapter page of a book. Zones can have sibling zones (to identify if/else 
conditions, where in only one of the two possible paths can be taken {Zones 4 and 7 in Fig. 
1}) or child zones (to identify nested control structures {Zone 10 being child of zone 8 in Fig. 
1 }). Zone types can be either simple or loopy in nature (to identify iterative loop structures). 
The tree is scanned node by node and decisions are taken to start a new zone or end an 
existing zone at key points such as circles, dots and exit squares. By default, when a circle is 
visited for the first time, the branch taken path is followed. But this node along with the 
newly started zone is stored in a queue for a later visit along the branch not taken path. When 
the structure has been traversed along the "branch taken" paths, the nodes with associated 
zones are popped out from the stack and traversed along their "branch not taken" paths. This 
is done till all nodes have been scanned and stack is empty. 

The Pseudo code for the process of Fig. 45 is given below: 

Global variables: pop flag = 0, tree_empty = 0; 
H56l58v2 87 
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Zonise (node) /* input into the function is the current node, a starting node */ 

{ 

while (tree_empty = 0) /* this loop goes on node by node in the tree till all 

node 

5 have been scanned */ 

{ 

if (node — >type = circle) 

{ 

if (pop_flag != set) /* pop flag is set when a pop operation is done */ 
10 { 

/* an entry here means that the circle was encountered for the 

first 

time */ 

/* so set the node— ►visited flag */ 
1 5 /* close the zone */ 

/* since u r entering a virgin circle, u cant create the new zone 

as a 

sibling to the one u just closed */ 
/* if the zone u just closed, has a valid Anchor Point and if its 
20 of 

type Loop and if its visited flag is set, then u cannot create a 

child zone */ 
/* accordingly create a new zone */ 
/* set child as current zone*/ 
25 /* push this zone and the node into the queue */ 

/* take the taken path for the node, i.e node = node—* taken */ 

} 

if (pop_flag = set) 
{ 

30 /* an entry here means, that we r visiting a node and its 

associated 

zone, that have just been popped out form the queue, hence 
revisiting an old node */ 
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/* since this node has its visited flag as set, change that flag 

value 

to -1, so as to avoid any erroneous visit in the future */ 
/* if node is of type Non Loop, then spawn a new sibling zone 

5 */ 

/* if node is of type Loop, then spawn new zone as laterparent 

zone 

and mark zone type as loop*/ 
/* choose the not taken path for the node */ 

10 } 
} 

else if (node— »type = exit square) 

{ 

/* close the zone */ 

15 /* if the closed zone has a parent, i.e zone— ^parent pointer is not 

NULL, 

then create a new zone with link to the parent zone as type next zone 

*/ 

/* if the closed zone does not have a parent, then spawn a new zone 

20 that is 

next to the closed zone */ 
/* choose the not taken path for the node */ 

} 

else if (node— >type is dot and node— >taken = NULL) 
25 { 

/* close zone */ 

/* choose node to be considered next by popping out from the queue */ 
/* in case the queue is empty, all nodes in tree have been scanned */ 
/* set pop flag */ 

30 } 

else if (node— >type = dot and node— >taken !== NULL) 

{ 

/* this is just a break in the current zone */ 
/* create temp stopl and tempstartl pointers*/ 
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observed among them. These form the basis of extraction of parallelism at the level of zones. 
A zone inside a control structure is the Mater child' of the zone outside the structure. Hence 
the zone outside a control structure and occurring before (in code sequence) the zone inside a 
control structure is a 'former parent' of the zone present inside. But, the zone outside a 
10 control structure and occurring after (in code sequence) the zone inside the structure is 

referred to as the Mater parent'. Similarly the child in this case would be a 'former child'. A 
zone occurring after another zone and not related through a control structure is the 'next' of 
the earlier one. After parsing through the structure thru the zonal relationship as shown in 
Fig. 46 is obtained. 

15 This is referred to as the 'initial zone structure'. The term initial, is used because, 

some links need to be created and some existing ones, need to be removed. This process is 
explained in the section below. 

Step 6: Further Modification of the 'initial zone structure' 



20 the existing set of links and others are redundant. For example in Fig. 46, we see that Zl can 

be connect to Z2 thru 'n' 

Z12 can be connected to Z13 thru Mp' 

Z13 can be connected to Z6 thru 'n' 

Z8 can be connected to Z9 thru 'n' 
25 Z4 can be connected to Z5 thru Mp' 

Z5 can be connected to Zl 3 thru Mp' 

Z7 can be connected to Z5 thru Mp' 

But Z8's relationship to Z6 thru Mp' is false, coz no node can have both 'n' and Mp' 

links. 

30 In such a case, the Mp' link should be removed. 

Therefore some rules need to be followed to establish 'n' and Mp' type links, if they 
don't exist. 



Some of the relationships that were discussed in the previous step cannot exist with 



To form an 'n' link: 
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If a zone (1) has an 'lc' link to zone (2), and if that zone (2) has a 'lp' link to a zone 
(3), then an 6 n' link can be established between 1 and 3. This means that if zone (1) is of type 
'loop', then zone (3) will now be classified as type 'loop' also. 

To form an 'lp' type links if it doesn't exist: 

If a zone (1) has an c fp' link to zone (2), and if that zone (2) has an 'n' link to a zone 
(3), then an 'lp' link can be established between 1 and 3 

If a zone (1) has an Mp' link to zone (2), and also has an 'n' link to zone (3), then first, 
remove the 'lp' link 'to zone (2)' from zone (1) and then, place an 'lp' link from zone (3) to 
zone (2). 

This provides the 'comprehensive zone structure' as shown in Fig. 47 (with cancelled 
links) and in Fig. 48 (with all cancelled links removed). 

To identify parallelism and hence compulsorily sequential paths of execution, the 
following approach is adopted. First, the comprehensive zone structure obtained, is ordered 
sequentially by starting at the first zone and traversing along an 'lc — lp' path. If a Sibling link 
is encountered it is given a parallel path. The resulting structure is shown in Fig. 49. 

To establish parallelism between a zone (1) of loop count A and its upper zone (2) of 
loop count B, where A < B, check for data dependency between zone 1 and all zones above 
it up to and including the zone with the same loop count as zone 2. 

In the example above, to establish parallelism b/w zone 6 and zone 9, check for 
dependencies b/w zone 6 and 9, 10, 8. If there is no dependency then zone 6 is parallel to 
zone 8. 

To establish parallelism between a zone (1) of loop count A and its upper zone (2) of 
loop count B, where A = B, direct dependency check needs to be performed. 

To establish parallelism between a zone (1) of loop count A and its upper zone (2) of 
loop count B, where A > B, direct dependency check needs to be performed. Then, the zone 
(1) will now have to have an iteration count of (its own iteration count * zone (2)'s iteration 
count). 

When a zone rises like a bubble and is parallel with another zone in the primary path, 
and reaches a dependency, it is placed in a secondary path. No bubble in the secondary path 
is subjected to dependency testing. 

After a bubble has reached its highest potential, and stays put in a place in the 
secondary path, the lowest bubble in the primary path is checked for dependency on its upper 
fellow. 
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If the upper bubble happens to have a different loop count number, then as described 
earlier, testing is carried out. In case a parallelism cannot be obtained, then this bubble, is 
clubbed with the set of bubbles ranging from its upper fellow, till and inclusive of the bubble 
up the chain with the same loop count as its upper fellow. A global i/o parameter set is 
5 created for this new coalition. Now this coalition will attempt to find dependencies with its 
upper fellow. 

The loop count for this coalition will be bounding zone's loop count. Any increase in 
the iteration count of this coalition will reflect on all zones inside it. In case a bubble wants to 
rise above another one which has a sibling/ reverse sibling link, there will be speculative 
10 parallelism. 

The algorithm should start at multiple points, one by one. These points can be 
obtained by starting from the top zone and traversing down, till a sibling split is reached. 

Then this zone should be remembered, and one of the paths taken. This procedure is 
similar to the stack saving scheme used earlier in the zonise function. 
15 Another Pre-processing step is used that loop unrolls every iterative segment of a 

CDFG that does not have conditional branch instructions inside it and whose iterative count 
is known at compile time. 

Although preferred embodiments of the invention have been described in detail, it 
will be readily appreciated b those skilled in the art that further modifications, alterations and 
20 additions to the invention embodiments disclosed may be made without departure from the 
spirit and scope of the invention as set forth in the appended claims. 



! 156l58v2 



Au^^. Docket No. 913S-0I4S 



Appendix A: 

#include<stdio.h> 
void mainO 
{ 

5 int ij,k,l; 

i= 10; 
j = 1*4; 
if(j>5) 
{ 

10 k=findsum(ij); 
1 = 4+k; 

} 

else 
{ 

15 k = findsum(i j); 

l = k*10; 

} 

} 

int findsum(int a,int b) 
20 { 

int ij,k; 
k=4; 

for(i=0;i<10;i-H-) 
k = k+l; 
25 j = findsub(k,a); 

return j; 

} 

int findsub(int x,int y) 

{ 

30 int t; 

t = x-y; 
return(t); 

} 
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Appendix B: 
Main.s 

.file "main.c" 
gcc2_compiled. : 



5 


.section 


".text" 




.align 4 




.global 


main 




.type 


main,#fiinction 




.proc 


020 


10 


main: 






!#PROLOGUE# 0 




save 


%sp, -128, %sp 




!#PROLOGUE# 1 




mov 


10, %o0 


15 


St 


%o0, [%fp-20] 




mov 


4, %o0 




St 


%o0, [%fp-24] 




Id 


[%fp-24], %o0 




cmp 


%o0, 5 


20 


ble 


.LL3 




nop 






Id 


[%fp-20], %o0 




Id 


[%fp-24],%ol 




call 


findsum, 0 


25 


nop 






St 


%o0, [%fp-28] 






[%fp-28], %o0 




add 


%o0, 4, %ol 




St 


%ol, [%fp-32] 


30 


b 


.LL4 




nop 






.LL3: 






ld 


[%fp-20], %o0 




ld 


[%fp-24], %ol 
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call findsum, 0 
nop 

st %o0, [%fp-28] 

Id [%fp-28], %o0 

mov %o0, %o2 

sll %o2, 2, %ol 

add %ol,%o0, %ol 

sll %ol,l,%o0 

st %o0, [%fp-32] 
.LL4: 
.LL2: 

ret 

restore 
.LLfel: 

.size main,.LLfel-main 

.ident "GCC: (GNU) 2.95.2 19991024 (release)" 
Findsum.s 

.file "findsum.c" 
gcc2_compiled. : 
.section ".text" 

.align 4 

.global findsum 
.type findsum,#function 
.proc 04 
findsum: 

!#PROLOGUE# 0 
save %sp, -128, %sp 
!#PROLOGUE# 1 
st %i0, [%fp+68] 
st %il, [%fp+72] 
mov 4, %o0 
st %o0, [%fp-28] 
st %g0, [%fp-20] 



.LL3: 
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Id [%fb-20], %oO 

cmp %oO, 9 

ble .LL6 
nop 

b .LL4 
nop 
.LL6: 

Id [%fp-28], %o0 

add %o0, l,%ol 

st %ol,[%fp-28] 
.LL5: 

Id [%fp-20], %o0 

add %o0, l,%ol 

st %ol, [%fp-20] 

b .LL3 
nop 
.LL4: 

Id [%fp-28], %o0 

Id [%fp+68], %ol 

call findsub, 0 
nop 

st %o0, [%fp-24] 

Id [%fp-24], %o0 

mov %o0, %i0 

b .LL2 
nop 
.LL2: 
ret 

restore 
.LLfel: 

.size findsum,.LLfe 1 -findsum 

.ident "GCC: (GNU) 2.95.2 19991024 (release) 
Findsub.s 

.file "findsub.c" 
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gcc2_compilecl: 
.section ".text" 
.align 4 

.global findsub 
.type findsub,#function 
.proc 04 
findsub: 



!#PROLOGUE# 0 


save 


%sp, -120, %sp 


!#PROLOGUE# 1 


St 


%i0, [%fp+68] 


St 


%il, [%fp+72] 


Id 


[%fp+68], %o0 


Id 


[%fp+72], %ol 


sub 


%o0,%ol,%o0 


st 


%o0, [%fp-20] 


Id 


[%fp-20], %o0 


mov 


%o0, %i0 


b 


.LL2 


nop 





.LL2: 
ret 

restore 



.LLfel: 

.size findsub,.LLfel -findsub 

.ident "GCC: (GNU) 2.95.2 19991024 (release)" 
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Appendix C: 

Expanded main function 

Function main BEGINS here 
save %sp-128%sp 
5 mov 10%o0 

st %o0 [%fp-20] 
mov 4 %o0 
st %o0 [%fp-24] 
Id [%fp-24]%o0 
10 cmp %o0 5 

ble 0 
nop 

Id [%fp-20]%o0 

Id [%fp-24]%ol 
1 5 Function findsum BEGINS here 

save %sp-128%sp 

st %i0 [%fp+68] 

st %il [%fp+72] 

mov 4 %o0 
20 st %o0 [%fp-28] 

st %g0 [%fp-20] 

4 

Id [%fp-20]%o0 
cmp %o0 9 
25 ble 5 

nop 
b 6 
nop 
5 

30 Id [%fp-28]%o0 

add %o0 1 %ol 
st %ol [%fp-28] 
7 

Id [%fp-20]%o0 
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add %oO 1 %ol 

st %ol [%fp-20] 

b 4 

nop 
5 6 

Id [%fp-28]%o0 

Id [%fp+68]%ol 

Function findsub BEGINS here 

save %sp-120%sp 
10 st %i0 [%fp+68] 

st %il [%fp+72] 

Id [%fp+68]%o0 

Id [%fp+72]%ol 

sb %o0%ol %o0 
15 st %o0 [%fp-20] 

Id [%fp-20]%o0 

mov %o0%i0 

b 10 

nop 
20 10 

ret 

restore 
11 

Function findsub ENDS here 
25 findsub .LLfel -findsub 

nop 

st %o0 [%fp-24] 
Id [%fp-24]%o0 
mov %o0%i0 
30 b 8 

nop 
8 

ret 

restore 
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9 

Function findsum ENDS here 
findsum .LLfel -findsum 
nop 

5 st %o0 [%fp-28] ' 

Id [%fp-28]%o0 
add %o0 4%ol 
st %ol [%fp-32] 
b 1 

10 nop 
0 

Id [%fp-20]%o0 

Id [%fp-24]%ol 

Function findsum BEGINS here 
15 save %sp-128%sp 

st %i0 [%fp+68] 

st %il [%fp+72] 
• mov 4 %o0 

st %o0 [%fp-28] 
20 st %g0 [%fp-20] 

4 

Id [%fp-20]%o0 
cmp %o0 9 
ble 5 
25 nop 
b 6 
nop 
5 

Id [%fp-28]%o0 
30 add %o0 1 %ol 

st %ol [%fp-28] 
7 

Id [%fp-20]%o0 
add %o0 1 %ol 
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st %ol [%fp-20] 

b 4 

nop 

6 

5 Id [%fp-28]%o0 

Id [%fp+68]%ol 

Function findsub BEGINS here 

save %sp - 1 20 %sp 

st %i0 [%fp+68] 
10 st %il [%fp+72] 

Id [%fp+68]%o0 

Id [%fp+72]%ol 

sb %o0%ol %o0 

st %o0 [%fp-20] 
15 Id [%fp-20]%o0 

mov %o0%i0 

b 10 

nop 

10 

20 ret 

restore 
11 

Function findsub ENDS here 
findsub .LLfel -findsub 
25 nop 

st %o0 [%fp-24] 
Id [%fp-24]%o0 
mov %o0%i0 
b 8 

30 nop 
8 

ret 

restore 
9 
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Function findsum ENDS here 
findsum .LLfel -findsum 
nop 

st %o0 [%fp-28] 
Id [%fp-28]%o0 
mov %o0%o2 
sll %o2 2%ol 
add %ol %o0 %ol 
sll %ol 1 %o0 
st %o0 [%fp-32] 
1 
2 

ret 

restore 
3 

Function main ENDS here 
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Appendix D : 

In this section the pseudo ANSI C codes for the test-bench algorithms are presented. 
Note: For an indepth-analysis and explanation on all graphics algorithms, please refer to the 
book: "Computer Graphics: Principles and Practise" Second edition in C, by Foley, van 
Dam, Feiner and Hughes. 
Cohen Sutherland Line Clipping 
typedef unsigned int outcode; 

enum {TOP=0xl, BOTTOM=0x2, RIGHT=0x4, LEFT=0x8}; 
void CohenSutherlandLineClipAndDraw ( 

double xO, double yO, double xl, double yl, double xmin, double xmax, 

double ymin, double ymax, int value) 
/* Cohen-sutherland clipping algorithm for line P0 = (x0,y0) to PI = (xl,yl) and */ 
/* clip rectangle with diagonal from (xmin,ymin) to (xmax,ymax) */ 

{ 

/* Outcodes for P0, PI and whatever point lies outside the clip rectangle */ 

outcode outcodeO, outcode 1, outcodeOut; 

boolean aacept = FALSE, done = FALSE; 

outcodeO = CompOutCode (x0,y0,xmin,xmax,ymin,ymax); 

outcode 1 = CompOutCode (xl,yl ,xmin,xmax,ymin,ymax); 



if (! (outcodeO | outcode 1)) { 

accept = TRUE; done = TRUE; 
} else if (outcodeO & outcode 1) 

done = TRUE; 

else { 

double x,y; 

outcodeOut = outcodeO?outcodeO:outcodel; 

if (outcodeOut & TOP) { 

x = xO + (xl - x0)*(ymax - yO) / (yl - yO); 

y = ymax; 
} else if (outcodeOut & BOTTOM) { 

x = xO + (xl - x0)*(ymin - yO) / (yl - yO); 

y = ymin; 
} else if (outcodeOut & RIGHT) { 
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y = y0 + (yl- y0)*(xmax - xO) / (xl - xO); 
x = xmax; 

} else { 

y = yO + (yl - yO)*(xmin - xO) / (xl - xO); 
x = xmin; 

} 

if (outcodeOut = outcodeO) { 

xO = x; yO = y; outcodeO = CompOutCode 



} else { 

xl = x; yl = y; outcodel = CompOutCode 



outcode CompOutode ( 

double x, double y, double xmin, double xmax, double ymin, double ymax) 



outcode code = 0; 
if (y<ymax) 

code |= TOP; 
else if (y<ymin) 

code |= BOTTOM; 
if (x>xmax) 

code |= RIGHT; 
else if (x<xmin) 

code |= LEFT; 
return code; 

} 

void MidpointLineReal (double x0,double yo,double xl, double yl, double value) 

{ 
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double dx = xl - xO; 
double dy = yl - yO; 
double d = 2*dy - dx; 
double incrE = 2*dy; 
5 double incrNE = 2*(dy - dx); 

double x = xO; 
double y = yO; 
WritePixel (x,y, value); 
while (x<xl) { 
10 if (d<=0) { 

d += incrE; 

x++; 

} else { 

d += incrNE; 
15 x++; 

y++; 

} 

WritePixel (x,y,value); 

} 

20 } 

Mid-point Ellipse Scan Conversion 

void MidpointEllipse (int a, int b, int value) 

/* Assumes center of ellipse is at the origin. Note that overflow may occur */ 
/* for 16-bit integers because oft the squares */ 
25 { 

double d2; 
int x=0; 
int y = b; 

double dl = b 2 - (a 2 b) + (0.25a 2 ); 
30 EllipsePoints (x,y, value); /* The 4-way symmetrical WritePixel */ 

while (a 2 (y - 0.5) > b 2 (x + 1)) { 
if(dl<0) 

dl +=b 2 (2x + 3); 

else { 
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dl += b 2 (2x + 3) + a 2 (-2y + 2); 

y-s 

} 

x++; 

5 ElIipsePoints(x,y,value); 
} 

d2 = b 2 (x + 0.5) 2 + a 2 (y - l) 2 - aV; 
while (y > 0) { 

if(d2<0) { 

10 d2 += b 2 (2x + 2) + a 2 (-2y + 3); 

x++; 

} else 

d2 += a 2 (-2y + 3); 

y-s 

1 5 EllipsePoints(x,y, value); 

} 

} 

The bitBlock Transfer Algorithm 

typedef struct { 
20 point topLeft, bottomRight; 

} rectangle; 
typedef struct { 
cha *base; 
int width; 
25 rectangle rect; 

} bitmap; 
typedef struct { 

unsigned int bits: 32; 
} texture; 
30 typedef struct { 

char *worldptr; 
int bit; 
} bitPointer; 
void bitBlt( 
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bitmap mapl; 
point point 1; 
texture tex; , 
bitmap map2; 
rectangle rect2; 
writeMode mode) 



int width; 
int height; 
1 0 bitPointer p 1 ,p2; 

clip x_values; 
clip y-values; 

width = rect2.bottomRight.x - rect2.topLeft.x; 
height = rect2.bottomRight.y - rect2.topLeft.y; 
1 5 if (width < 0 || height < 0) 

return; 
pi .wordptr = mapl .base; 
p 1 .bit = map 1 .rect.topLeft.x % 32; 

/* And the first bin in the bitmap is a few bits further in */ 
20 /* Increment pi unitl it points to the specified point in the first bitmap */ 

IncrementPointer (pi ,pointl .x - mapl .rect.topLeft.x + mapl .width * 

(point 1 .y - mapl .rect.topLeft.y)); 
/* Same for p2 - it points to the origin of the destination rectangle */ 
p2.worldptr = map2.base; 
25 p2.bit = map2.rect.topLeft.x % 32; 

IncrementPointer (p2,rect2.topLeftx - map2.rect.topLeft.x + 

map2.widrh * (rect2.topLeft.y 

map2.rect.topLeft.y)); 
if(pl< P 2){ 

30 /* The pointer pi comes before p2 in memory; if they are in the same bitmap 

*/ 

/* the origin of the source rectangle is either above the origin for the */ 
/* above destination or, if at the same level, to the left of it */ 
IncrementPointer (pi, height * mapl .width + width); 
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/* Now pi points to the lower right word of the rectangle */ 
IncrementPointer (p2, height * mapl. width + width); 
/* Same for p2, but the destination rectangle */ 
point 1.x += width; 
point 1 .y += height; 

/* Thios point is now just beyond the lower right in the rectangle */ 
while (height-- >0){ 

/* Copy rows from the source to the target bottom to top, right to left */ 

DecrementPointer (pi, mapl. width); 

DecrementPointer (p2, map2. width); 

temp_y = pointl .y % 32; /* used to index into texture */ 

tempx = pointl .x % 32; 

/* Now do the real bitBlt from bottom right to top left */ 
RowBltNegative (pi, p2, width, BitRotate(tex[temp_y],temp_x), 



} /* while */ 
} else {/* if pi >=p2 */ 

while (height- > 0) { 
/* Copy rows from source to destaination, top to bottom, left to right */ 
/* Do the real bitBlt, from topleft to bottom right */ 



} /* else */ 
} /* bitBlt */ 

void Clip Values (bitmap *mapl, bitmap *map2, point *pointl, rectangle *rect2) 

{ 

if (*pointl not inside *mapl){ 



mode); 



RowBltPositive (same arguments as before); 



increment pointers; 



} /* while */ 



adjust *pointl to be inside *mapl; 



adjust origin of *rect2 by the same amount; 
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} 

if (originof *rect2 not inside *map2){ 

adjust origin of *rect2 to be inside *map2; 
adjust *pointl by the same amount; 

5 } 

if (opposite corner of *rect2 not inside *map2) 

adjust opposite corner of *rect2 to be inside; 

if (opposite corner of corresponding rectangle in *mapl not inside *mapl) 

adjust opposite corner of rectangle; 
10 } /*Clip Values */ 

void RowBltPositive( 

bitPtr pi , bitPtr p2; /* Source and destination pointers */ 
int n; /* How many bits to copy */ 

char tword; /* Texture word */ 

1 5 write Mode mode) /* Mode to bit pixels */ 

{ 

/* Copy n bits from position pi to position p2 according to the mode */ 
while (n~ > 0) { 

if (BitlsSet (tword,32))/* If texture says it is OK to copy..*/ 
20 MoveBit (pi ,p2,mode); /* then copy the bit */ 

IncrementPointer (pi); 

IncrementPointer (p2); 

RotateLeft (tword); /* Rotate bits in tword to the left */ 

} /* while */ 
25 } /RowBltPositive */ 
Phong Shading 
double dbl=2.5,db2=65535.,pi; 
int colors[]={3,6,10,13,6,3,10,13,6,3, 13,10}, 
d[]={640,350,l}> 
30 i,k, 

palette[]= {000,0 1 0,00 1 ,0 1 1 ,020,002,022,077, 
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040,004,044,060,006,066,007,077}, 
x,y,x_min,x_max,y_min,y_max; 
int min,sec; 

unsigned short random; 
5 main() 
{ 

double a,b,c,10,ll,12,ln,lnl,n0,nl,n2,p,q,r=128,s,t,v[12][3]; 
int n; 

int graphdriver = DETECT, graphmode; 
1 0 int color; 

initgraph(&graphdriver, &graphmode, ""); 
/* for(n=0;n<16;n++) */ 
#ifdef Intel 

printf("\n\t\t 80387 Phong Shading Demonstration Program\n"); 
15 #else 

printf("\n\t\t\t Phong Shading Demonstration^"); 
#endif 

/* printf("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n M ); 

start=clock ( ) ; */ 

20 /* Pixel aspect ratio. Original value is 1.3 which works with EGA*/ 
/* This is hence the version for my - ThL - EIZO VGA Card */ 
a=1.0; 

/* Screen center coordinates */ 
b=0.5*(d[0]-l); /* x-position */ 
25 c=0.5*(d[l]-l); /* y-position */ 

/* Unit length light source vector */ 

10=-l/sqrt(3.); 

11=10; 

12=-10; 

30 /* Ratio circumference to diameter of a circle */ 
pi=4*atan(l.); 

/* A dozen vertices evenly spread over a unit sphere */ 

v[0][0]=0; 

v[0][l]=0; 
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v[0][2]=l; 
s=sqrt(5.); 

for(i=l;i<ll;i++) { 
p=pi*i/5; 
5 v[i][0]=2*cos(p)/s; 
v[i][l]=2*sin(p)/s; 
v[i][2]=(l.-i%2*2)/s; 

} 

v[ll][0]=0; 
10 v[ll][l]=0; 
v[H][2]=-l; 

/* Loop to Phong shade each pixel */ 
y_max=c+r; 
y_min=2*c-y_max; 
15 for (y=y_m i n ; y <=y_max ; y ++) { 
s=y-c; 
nl=s/r; 
lnl=ll*nl; 
s=r*r-s*s; 
20 x_max=b+a*sqrt(s); 
x_min=2*b-x_max; 
for (x=x_min;x<=x_max;x++) { 
t=(x-b)/a; 
n0=t/r; 
25 t=sqrt(s-t*t); 
n2=t/r; 

/* Compute dot product and clamp to positive value */ 
In=10*n0+lnl+12*n2; 
if(ln<0) ln=0; 
30 /* cos(e.r)**27 */ 

t=ln*n2; 
t+=t-12; 
t*=t*t; 
t*=t*t; 
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t*=t*t; 

/* Nearest vertex to normal yields max dot product */ 
/* Get its color */ 
for (i=0,p=0;i<ll;i++) 
5 if(p<(q=n0*v[i][0]+nl*v[i][l]+n2*v[i][2])) { 

p=q; 

k=colors[i]; 
}/*end for*/ 

/* Aggregate ambient, diffuse, and spectacular intensities 
10 do dither*/ 

random=37*random+l ; 
i=k-db 1 +db 1 *ln+t+random/db2; 

/* Clamp values outside range of three color level to black or white */ 
if (i < (k-2)) i=0; 
15 else 

if(i>k)i=15; 
putpixel(x,y,i); 
}/*end for*/ 
}/*end for*/ 
20 exit: 

delay(SOOO); 
closegraph(); 
}/*end main*/ 
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Appendix E : 

Algorithm: 

Task schedule (G(V f E) f CTRL_VARS[N], PE = {PE1,PE2 PEM}) 

For each combination of CTRL VARS do 
5 { 

Generate a DFG Gsub(V,E,CTRL_VARS[I]) which is a sub-graph ofG(V,E). Only the 
nodes and edges in the control flow corresponding to the current combination of 
CTRL_ VARS are included in this sub-graph. 

Generate the PCP schedule of Gi. Let the schedule be PCP_sched[I] and the delay be 
10 PCP_delayfIJ. 
} 

Sort PCPjsched and PCPjdelay and Gsub in decreasing order of PCPjdelay [I] . 
Generate the Branch and bound schedule for GsubfOJ, the sub-graph with the worst 
PCPjdelay. Let the schedule be BB_sched[I=0] and the delay be BB_delay[I=0] 
1 5 Initialize worst _bb delay = BBjdelay[0] 

For all the other sub-graphs do 

{ 

if (PCPjdelay [I] < worst _bb_delay) then 
BB_sched[I] = PCP_sched[I] ; 
20 BB_delay[I] = PCP_delay[I] ; 

else 

Generate BB_sched[I] and BB delay [I] ; 
If(BB_delayfIJ > worst_bbjdelay[I]) then 
Worst Jbbjielay = BB_delay[I]; 

25 } 

Generate the branching tree with the help of the G(V,E). In this branching tree, the edge 
represents the choices (Kand K') and the node represents the variable (K) 
Initialize the current path to the one leading from the top to the leaf in such a way that the 
DFG corresponding to this path gives the worst _bb_delay. The path is nothing but a list 
30 of edges tracing from the top node till the leaf 
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We claim: 

1 1 . A method of fabricating a reconfigurable processor for running moderately 

2 complex programming applications comprising: 

3 (a) providing source code for a programming application, 

4 (b) entering the source code in a control flow graph generating compiler 

5 to produce a control data flow graph of data flow control flow and branch points, 

6 (c) extracting from the control flow graph basic blocks of code lying 

7 between branch points, 

8 (d) from the code lying between the branch points generating 

9 intermediate data flow graphs, 

10 (e) identifying clusters shared among dfgs at the highest level of 

1 1 granularity, 

12 (f) from the identified clusters determine the largest common subgraph 

1 3 shared among the dfgs, 

14 (g) scheduling the largest common subgraph for fast accomplishment of 

15 operations in the lcsg, 

16 (h) applying the scheduled lcsg to the intermediate flow graphs replacing 

1 7 the unscheduled lcsg therein, 

18 (i) scheduling the intermediate flow graphs containing the lcsg's for fast 

1 9 accomplishment of operations in the intermediate flow graphs to derive data patches having 

20 operations and timings of each intermediate flow graph, 

21 (j) combining the data patches to include operations and timing of the 

22 lcsg with operations and timings of each intermediate subgraph that are outside the lcsg, 

23 (k) from the combined data patches scheduling for process time 

24 reduction multiple uses of the lcsg operations and timings necessary to accomplish 

25 operations and timings of all intermediate subgraph employing the lcsg , and 

26 (1) implementing in hardware having mixed granularities the operations 

27 and timing of the lcsg including: 

28 (i) partitioning, 

29 (ii) placing, and 

30 (iii) interconnection routing. 
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2. 



In a method of making an integrated circuit for use as a hardware 



2 implemented part of a programmed operation implemented in software and hardware; the 

3 improvement comprising identifying hardware circuit elements for execution of a largest 

4 common subgraph common among a set of flow graphs representing the programmed 

5 operation; partitioning into blocks the circuit elements; arranging the blocks on an area 

6 representative of an available area of a surface of a substrate on which the circuit elements 

7 are to be formed; routing interconnections among the blocks; partitioning into sub-blocks 

8 the circuit elements of each block; arranging each sub-block on an area representative of 

9 the block from which it has been partitioned, routing interconnections among the sub- 

10 blocks and iteratively partitioning and routing among lesser sub-blocks until the individual 

1 1 circuit elements have been placed and routed. 

1 3. The method according to claim 2, wherein the steps of routing comprise 

2 locating conductors and switches for interconnections among blocks, sub-blocks and circuit 

3 elements. 

1 4. The method according to claim 3, wherein locating conductors and switches 

2 further comprises locating variable switches to effect variable conductive paths among the 

3 blocks, sub-blocks and circuit elements. 

1 5. A method of scheduling process elements of hardware implementing a 

2 program operation, comprising: 

3 (a) developing a control data flow graph from the software; 

4 (b) using a first, non-exhaustive scheduling algorithm to relatively 

5 quickly arrive at a first scheduling of the process elements; 

6 (c) using a second more exhaustive scheduling algorithm for at least one 

7 and less than all selected paths of the control data flow graph to reduce the time of 

8 execution thereof; and 

9 (d) once all paths of the control data flow graph have been scheduled, 

10 including all of the second more exhaustive scheduling, merging all of schedules, 

1 1 respecting data and resource dependencies. 

1 6. The method of scheduling according to claim 5, wherein step (b) comprises 

2 PCP scheduling. 
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1 7. The method of scheduling according to either claim 5 or 6, wherein step (c) 

2 comprises branch and bound based scheduling. 

1 8. A dedicated integrated circuit for performing the program operation having 

2 processing elements scheduled according to claim 5. 

1 9. A dedicated integrated circuit for performing the program operation having 

2 processing elements scheduled according to claim 6. 

1 1 0. A dedicated integrated circuit for performing the program operation having 

2 processing elements scheduled according to claim 7. 

1 11. The method of forming an application specific reconfigurable circuit, 

2 comprising: 

3 (a) providing source code for an application to be run b the circuit, 

4 (b) deriving flow graphs representing separate portions of the 

5 application, 

6 (c) identifying at least one largest common flow graph from at least two 

7 of the separate portions of the application; and 

8 (d) in hardware, configuring circuitry to be shared by the separate 

9 portions of the application. 
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ABSTRACT 



A method of producing a reconfigurable circuit device for running a computer 
program of moderate complexity such as multimedia processing. Code for the application 
is compiled into Control Flow Graphs representing distinct parts of the application to be 
run. From those Control Flow Graphs are extracted basic blocks. The basic blocks are 
converted to Data Flow Graphs by a compiler utility. From two or more Data Flow Graphs 
a largest common subgraph is determined. The largest common subgraph is ASAP 
scheduled and substituted back into the Data Flow Graphs which also have been scheduled. 
The separate Data Flow Graphs containing the scheduled largest common subgraph are 
converted to data paths that are then combined to form code for operating the application. 
The largest common subgraph is effected in hardware that is shared among the parts of the 
application from which the Data Flow Graphs were developed. Scheduling of the overall 
code is effected for sequencing, providing fastest run times and the code is implemented in 
hardware by partitioning and placement of processing elements on a chip and design of the 
connective fabric for the design elements. 
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